mbox series

[0/2] xfs: fix stale disk exposure after crash

Message ID 157915534429.2406747.2688273938645013888.stgit@magnolia (mailing list archive)
Headers show
Series xfs: fix stale disk exposure after crash | expand

Message

Darrick J. Wong Jan. 16, 2020, 6:15 a.m. UTC
Hi all,

These two patches try to shrink the window during which a crash during
writeback can expose stale disk contents.  The first patch causes
delalloc reservations to be converted to unwritten extents for any
writeback that's going on within EOF.

The second patch selectively relaxes the unwritten writeout requirement
when the entire file is being flushed (ala fsync) and ensures that
writeback of a range after the ondisk EOF is expanded downwards to the
old EOF to ensure that increasing a file's size doesn't leave us
vulnerable to exposure of stale disk contents from a previous
speculative allocation.

This solves the regressions in generic/536 and generic/042.

If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.

This has been lightly tested with fstests.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=stale-exposure

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=stale-exposure

Comments

Christoph Hellwig Jan. 16, 2020, 4:49 p.m. UTC | #1
Btw, what happened to:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=djwong-wtf&id=c931d4b2a6634b94cc11958706592944f55870d4

?
Darrick J. Wong Jan. 16, 2020, 11 p.m. UTC | #2
On Thu, Jan 16, 2020 at 08:49:55AM -0800, Christoph Hellwig wrote:
> Btw, what happened to:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=djwong-wtf&id=c931d4b2a6634b94cc11958706592944f55870d4

Originally I thought that it was enough to decrease *wbc->range_start to
the ondisk EOF since the _flush_unmap function triggers a writepages
call.  Maybe it's better to make that part explicit.

However, it's only necessary to extend writeback like that if you're
going to retain the delalloc -> written state change.  I don't consider
applying patch 2 to be a good idea though.

--D

> ?