Re: [PATCH] iomap: Ensure iop->uptodate matches PageUptodate

[Dave Chinner <david@fromorbit.com>]

On Mon, Jul 27, 2020 at 12:20:22AM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 09:06:57AM +1000, Dave Chinner wrote:
> > On Sun, Jul 26, 2020 at 10:10:52AM +0100, Matthew Wilcox (Oracle) wrote:
> > > If the filesystem has block size < page size and we end up calling
> > > iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits
> > > would be zero, which causes us to skip writeback of blocks which are
> > > !uptodate in iomap_writepage_map().  This can lead to user data loss.
> > 
> > I'm still unclear on what condition gets us to
> > iomap_page_mkwrite_actor() without already having initialised the
> > page correctly. i.e. via a read() or write() call, or the read fault
> > prior to ->page_mkwrite() which would have marked the page uptodate
> > - that operation should have called iomap_page_create() and
> > iomap_set_range_uptodate() on the page....
> > 
> > i.e. you've described the symptom, but not the cause of the issue
> > you are addressing.
> 
> I don't know exactly what condition gets us there either.  It must be
> possible, or there wouldn't be a call to iomap_page_create() but rather
> one to to_iomap_page() like the one in iomap_finish_page_writeback().

Yes, I understand the code accepts it can happen; what I dislike is
code that asserts subtle behaviour can happen, then doesn't describe
that exactly why/how that condition can occur. And then, because we
don't know exactly how something happens, we add work arounds to
hide issues we can't reason through fully. That's .... suboptimal.

Christoph might know off the top of his head how we get into this
state. Once we work it out, then we need to add comments...

> > > reproduced on mainline using that test (the THP code causes iomap_pages
> > > to be discarded more frequently), but inspection shows it can happen
> > > with an appropriate series of operations.
> > 
> > That sequence of operations would be? 
> > 
> > > Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads")
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > ---
> > >  fs/iomap/buffered-io.c | 7 ++++++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > > index a2b3b5455219..f0c5027bf33f 100644
> > > --- a/fs/iomap/buffered-io.c
> > > +++ b/fs/iomap/buffered-io.c
> > > @@ -53,7 +53,10 @@ iomap_page_create(struct inode *inode, struct page *page)
> > >  	atomic_set(&iop->read_count, 0);
> > >  	atomic_set(&iop->write_count, 0);
> > >  	spin_lock_init(&iop->uptodate_lock);
> > > -	bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
> > > +	if (PageUptodate(page))
> > > +		bitmap_fill(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
> > > +	else
> > > +		bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE);
> > 
> > I suspect this bitmap_fill call belongs in the iomap_page_mkwrite()
> > code as is the only code that can call iomap_page_create() with an
> > uptodate page. Then iomap_page_create() could just use kzalloc() and
> > drop the atomic_set() and bitmap_zero() calls altogether,
> 
> Way ahead of you
> http://git.infradead.org/users/willy/pagecache.git/commitdiff/5a1de6fc4f815797caa4a2f37c208c67afd7c20b

*nod*

I would suggest breaking that out as a separate cleanup patch and
not hide is in a patch that contains both THP modifications and bug
fixes. It stands alone as a valid cleanup.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com