From: Brian Foster <bfoster@redhat.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Christoph Hellwig <hch@infradead.org>, Qian Cai <cai@redhat.com>
Subject: Re: [PATCH] iomap: Set all uptodate bits for an Uptodate page
Date: Thu, 24 Sep 2020 09:12:35 -0400 [thread overview]
Message-ID: <20200924131235.GA2603692@bfoster> (raw)
In-Reply-To: <20200924125608.31231-1-willy@infradead.org>
On Thu, Sep 24, 2020 at 01:56:08PM +0100, Matthew Wilcox (Oracle) wrote:
> For filesystems with block size < page size, we need to set all the
> per-block uptodate bits if the page was already uptodate at the time
> we create the per-block metadata. This can happen if the page is
> invalidated (eg by a write to drop_caches) but ultimately not removed
> from the page cache.
>
> This is a data corruption issue as page writeback skips blocks which
> are marked !uptodate.
>
> Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads")
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> Reported-by: Qian Cai <cai@redhat.com>
> Cc: Brian Foster <bfoster@redhat.com>
> ---
> fs/iomap/buffered-io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 8b6cca7e34e4..8180061b9e16 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -60,6 +60,8 @@ iomap_page_create(struct inode *inode, struct page *page)
> iop = kzalloc(struct_size(iop, uptodate, BITS_TO_LONGS(nr_blocks)),
> GFP_NOFS | __GFP_NOFAIL);
> spin_lock_init(&iop->uptodate_lock);
> + if (PageUptodate(page))
> + bitmap_fill(iop->uptodate, nr_blocks);
Thanks. Based on my testing of clearing PageUptodate here I suspect this
will similarly prevent the problem, but I'll give this a test
nonetheless.
I am a little curious why we'd prefer to fill the iop here rather than
just clear the page state if the iop data has been released. If the page
is partially uptodate, then we end up having to re-read the page
anyways, right? OTOH, I guess this behavior is more consistent with page
size == block size filesystems where iop wouldn't exist and we just go
by page state, so perhaps that makes more sense.
Brian
> attach_page_private(page, iop);
> return iop;
> }
> --
> 2.28.0
>
next prev parent reply other threads:[~2020-09-24 13:12 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 12:56 [PATCH] iomap: Set all uptodate bits for an Uptodate page Matthew Wilcox (Oracle)
2020-09-24 13:12 ` Brian Foster [this message]
2020-09-24 13:59 ` Matthew Wilcox
2020-09-24 14:47 ` Gao Xiang
2020-09-24 15:12 ` Brian Foster
2020-09-24 15:22 ` Matthew Wilcox
2020-09-24 17:26 ` Brian Foster
2020-09-24 17:56 ` Matthew Wilcox
2020-09-24 15:08 ` Sedat Dilek
2020-09-24 15:15 ` Matthew Wilcox
2020-09-24 15:21 ` Sedat Dilek
2020-09-24 15:27 ` Matthew Wilcox
2020-09-24 16:19 ` Sedat Dilek
2020-09-24 16:36 ` Matthew Wilcox
2020-09-24 18:27 ` Sedat Dilek
2020-09-24 18:44 ` Matthew Wilcox
2020-09-24 18:47 ` Qian Cai
2020-09-24 19:54 ` Sedat Dilek
2020-09-24 20:02 ` Matthew Wilcox
2020-09-24 20:04 ` Sedat Dilek
2020-09-24 23:57 ` Matthew Wilcox
2020-09-25 2:13 ` Sedat Dilek
2020-09-25 10:44 ` Sedat Dilek
2020-09-25 11:12 ` Sedat Dilek
2020-09-25 13:24 ` Sedat Dilek
2020-09-25 13:36 ` Sedat Dilek
2020-09-25 13:46 ` Matthew Wilcox
2020-09-25 14:01 ` Sedat Dilek
2020-09-25 15:53 ` Matthew Wilcox
2020-09-26 19:12 ` Sedat Dilek
2020-09-27 11:31 ` Sedat Dilek
2020-09-27 12:04 ` Matthew Wilcox
2020-09-27 12:34 ` Sedat Dilek
2020-09-27 12:45 ` Sedat Dilek
2020-09-27 13:48 ` Sedat Dilek
2020-09-27 13:54 ` Matthew Wilcox
2020-09-27 14:02 ` Sedat Dilek
2020-09-27 15:19 ` Sedat Dilek
2020-10-03 18:52 ` Sedat Dilek
2020-10-04 4:13 ` Matthew Wilcox
2020-10-04 10:35 ` Sedat Dilek
2020-09-25 18:17 ` Darrick J. Wong
2020-09-28 6:41 ` Christoph Hellwig
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=20200924131235.GA2603692@bfoster \
--to=bfoster@redhat.com \
--cc=cai@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).