From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 1/3] xfs: flush new eof page on truncate to avoid post-eof corruption
Date: Thu, 29 Oct 2020 14:44:10 -0700 [thread overview]
Message-ID: <20201029214410.GI1061252@magnolia> (raw)
In-Reply-To: <20201029132325.1663790-2-bfoster@redhat.com>
On Thu, Oct 29, 2020 at 09:23:23AM -0400, Brian Foster wrote:
> It is possible to expose non-zeroed post-EOF data in XFS if the new
> EOF page is dirty, backed by an unwritten block and the truncate
> happens to race with writeback. iomap_truncate_page() will not zero
> the post-EOF portion of the page if the underlying block is
> unwritten. The subsequent call to truncate_setsize() will, but
> doesn't dirty the page. Therefore, if writeback happens to complete
> after iomap_truncate_page() (so it still sees the unwritten block)
> but before truncate_setsize(), the cached page becomes inconsistent
> with the on-disk block. A mapped read after the associated page is
> reclaimed or invalidated exposes non-zero post-EOF data.
>
> For example, consider the following sequence when run on a kernel
> modified to explicitly flush the new EOF page within the race
> window:
>
> $ xfs_io -fc "falloc 0 4k" -c fsync /mnt/file
> $ xfs_io -c "pwrite 0 4k" -c "truncate 1k" /mnt/file
> ...
> $ xfs_io -c "mmap 0 4k" -c "mread -v 1k 8" /mnt/file
> 00000400: 00 00 00 00 00 00 00 00 ........
> $ umount /mnt/; mount <dev> /mnt/
> $ xfs_io -c "mmap 0 4k" -c "mread -v 1k 8" /mnt/file
> 00000400: cd cd cd cd cd cd cd cd ........
>
> Update xfs_setattr_size() to explicitly flush the new EOF page prior
> to the page truncate to ensure iomap has the latest state of the
> underlying block.
>
> Fixes: 68a9f5e7007c ("xfs: implement iomap based buffered write path")
> Signed-off-by: Brian Foster <bfoster@redhat.com>
Seems reasonable,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
> ---
> fs/xfs/xfs_iops.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> index 5e165456da68..1414ab79eacf 100644
> --- a/fs/xfs/xfs_iops.c
> +++ b/fs/xfs/xfs_iops.c
> @@ -911,6 +911,16 @@ xfs_setattr_size(
> error = iomap_zero_range(inode, oldsize, newsize - oldsize,
> &did_zeroing, &xfs_buffered_write_iomap_ops);
> } else {
> + /*
> + * iomap won't detect a dirty page over an unwritten block (or a
> + * cow block over a hole) and subsequently skips zeroing the
> + * newly post-EOF portion of the page. Flush the new EOF to
> + * convert the block before the pagecache truncate.
> + */
> + error = filemap_write_and_wait_range(inode->i_mapping, newsize,
> + newsize);
> + if (error)
> + return error;
> error = iomap_truncate_page(inode, newsize, &did_zeroing,
> &xfs_buffered_write_iomap_ops);
> }
> --
> 2.25.4
>
next prev parent reply other threads:[~2020-10-29 21:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 13:23 [PATCH v2 0/3] misc iomap/xfs writeback fixes Brian Foster
2020-10-29 13:23 ` [PATCH v2 1/3] xfs: flush new eof page on truncate to avoid post-eof corruption Brian Foster
2020-10-29 15:04 ` Christoph Hellwig
2020-10-29 21:44 ` Darrick J. Wong [this message]
2020-10-30 23:23 ` Allison Henderson
2020-10-29 13:23 ` [PATCH v2 2/3] iomap: support partial page discard on writeback block mapping failure Brian Foster
2020-10-29 15:06 ` Christoph Hellwig
2020-10-29 15:27 ` Darrick J. Wong
2020-10-29 16:07 ` Brian Foster
2020-10-29 16:12 ` Darrick J. Wong
2020-10-29 16:33 ` [PATCH v2.1 " Brian Foster
2020-10-29 21:45 ` Darrick J. Wong
2020-10-30 23:23 ` Allison Henderson
2020-10-29 13:23 ` [PATCH v2 3/3] iomap: clean up writeback state logic on writepage error Brian Foster
2020-10-29 15:11 ` Christoph Hellwig
2020-10-29 21:48 ` Darrick J. Wong
2020-10-30 23:23 ` Allison Henderson
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=20201029214410.GI1061252@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.