From: Eryu Guan <eguan@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: flush the range before zero partial block range on truncate down
Date: Tue, 31 Oct 2017 18:09:58 +0800 [thread overview]
Message-ID: <20171031100958.GL17339@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20171028060529.GA29505@infradead.org>
On Fri, Oct 27, 2017 at 11:05:29PM -0700, Christoph Hellwig wrote:
> On Fri, Oct 27, 2017 at 08:53:28PM +0800, Eryu Guan wrote:
> > But it's possible that a buffer write overwrites the unwritten
> > extent, which won't be converted to a normal extent until I/O
> > completion, and iomap_truncate_page() skips zeroing wrongly because
> > of the not-converted unwritten extent. This would cause a subsequent
> > mmap read sees non-zeros beyond EOF.
>
> I suspect the right fix is to look at the in-core state im the iomap
> truncate helpers instead of doing a duplicate flush.
I may (and very likely) miss something, but my understanding is that
iomap_truncate_page() already looks at the in-core extent state provided
by xfs_file_iomap_begin()
xfs_setattr_size()
iomap_truncate_page()
iomap_zero_range()
iomap_apply()
xfs_file_iomap_begin() # finds extent according to the range
iomap_zero_range_actor() # sees iomap->type == IOMAP_UNWRITTEN
And this in-core extent state won't be converted to XFS_EXT_NORM until
writeback & I/O completion, so I think a flush is required.
Thanks,
Eryu
next prev parent reply other threads:[~2017-10-31 10:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-27 12:53 [PATCH] xfs: flush the range before zero partial block range on truncate down Eryu Guan
2017-10-28 6:05 ` Christoph Hellwig
2017-10-31 10:09 ` Eryu Guan [this message]
2017-10-31 17:11 ` Darrick J. Wong
2017-10-31 23:03 ` Dave Chinner
2017-10-31 22:58 ` Dave Chinner
2017-11-01 3:46 ` Eryu Guan
2017-11-01 4:44 ` Dave Chinner
2017-11-01 12:06 ` Eryu Guan
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=20171031100958.GL17339@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=hch@infradead.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.