Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Brian Foster <bfoster@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iomap: Ensure iop->uptodate matches PageUptodate
Date: Mon, 27 Jul 2020 09:53:35 +1000	[thread overview]
Message-ID: <20200726235335.GU2005@dread.disaster.area> (raw)
In-Reply-To: <20200726232022.GH23808@casper.infradead.org>

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

  reply	other threads:[~2020-07-26 23:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-26  9:10 Matthew Wilcox (Oracle)
2020-07-26 15:15 ` Christoph Hellwig
2020-07-26 23:06 ` Dave Chinner
2020-07-26 23:20   ` Matthew Wilcox
2020-07-26 23:53     ` Dave Chinner [this message]
2020-07-28  9:23       ` Christoph Hellwig
2020-07-28 13:15         ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200726235335.GU2005@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH] iomap: Ensure iop->uptodate matches PageUptodate' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).