Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

[Andrew Morton]

On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote:

> > I don't think the change is harmful. The worst case scenario is race with
> > write or truncate, but it's valid to return EOF in this case.
> > 
> > What scenario do you have in mind?
> > 
> 
> 1. File open on node A
> 2. Someone updates it on node B by extending the file
> 3. Someone reads the file on node A beyond end of original file size,
> but within end of new file size as updated by node B. Without the patch
> this works, with it, it will fail. The reason being the i_size would not
> be up to date until after readpage(s) has been called.
> 
> I think this is likely to be an issue for any distributed fs using
> do_generic_file_read(), although it would certainly affect GFS2, since
> the locking is done at page cache level,

Boy, that's rather subtle.  I'm surprised that the generic filemap.c
stuff works at all in that sort of scenario.

Can we put the i_size check down in the no_cached_page block?  afaict
that will solve the problem without breaking GFS2 and is more
efficient?

--
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/