Re: [PATCH v3] vfs: fix a bug when we do some dio reads with append dio writes

[Jan Kara <jack@suse.cz>]

On Mon 16-12-13 09:37:34, Steven Whitehouse wrote:
> Hi,
> 
> On Sat, 2013-12-07 at 18:55 +0800, Zheng Liu wrote:
> > From: Zheng Liu <wenqing.lz@taobao.com>
> > 
> > Currently we check i_size in buffered read path after we know the page
> > is update.  But it could return some zero-filled pages to the userspace
> > when we do some append dio writes.  We could use the following code
> > snippet to reproduce this problem in a ext2/3/4 filesystem.
> > 
> If the page is not uptodate, then neither (potentially) is i_size, since
> the underlying fs has not had a chance to get its own locks and update
> the inode size.
  Hum, this isn't really about page being uptodate or not, is it? It is
more about the fact that gfs2 updates i_size only from gfs2_readpage()
function when obtaining inode lock. Or do you know about other filesystem
having the same problem as gfs2? E.g. ocfs2 updates i_size from
ocfs2_file_aio_read() before calling generic_file_aio_read(), cannot gfs2
do something similar?

> I suspect that the correct fix would be to implement ->launder_page to
> avoid the race that you've identified here, if I've understood it
> correctly,
  I don't understand how that would work. Can you elaborate a bit? Here the
problem is i_size gets extended by DIO write during buffered read (which is
a fallback from DIO read) so we return zero-filled page instead of either
data filled page or short read. I don't see where launder_page() would come
into the picture...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR