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@xxxxxxxxxx> > > > > 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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
