Re: [Patch] invalidate range of pages after direct IO write

[Zach Brown]

Andrew Morton wrote:

> I'd be inclined to hold off on the macro until we actually get the
> open-coded stuff right..  Sometimes the page lookup loops take an end+1
> argument and sometimes they take an inclusive `end'.  I think.  That might
> make it a bit messy.
> 
> How's this look?

Looks good.  It certainly stops the worst behaviour we were worried
about.  I wonder about 2 things:

1) Now that we're calculating a specifc length for pagevec_lookup(), is
testing that page->index > end still needed for pages that get remapped
somewhere weird before we locked?  If it is, I imagine we should test
for < start as well.

2) If we get a pagevec full of pages that fail the != mapping test we
will probably just try again, not having changed next.  This is fine, we
won't find them in our mapping again.  But this won't happen if next
started as 0 and we didn't update it.  I don't know if retrying is the
intended behaviour or if we care that the start == 0 case doesn't do it.

I'm being less excited by the iterating macro the more I think about it.
   Tearing down the pagevec in some complicated for(;;) doesn't sound
reliable and I fear that some function that takes a per-page callback
function pointer from the caller will turn people's stomachs.

- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/