From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: fix corner cases for subpage generic/363 failures
Date: Fri, 11 Apr 2025 14:43:59 +0930 [thread overview]
Message-ID: <cover.1744344865.git.wqu@suse.com> (raw)
Test case generic/363 always fail on subpage (fs block fs < page size)
btrfses, there are mostly two kinds of problems here:
All examples are based on 64K page size and 4K fs block size.
1) EOF is polluted and btrfs_truncate_block() only zeros the block that
needs to be written back
0 32K 64K
| | |GGGGGGGGGGGGGG|
50K EOF
The original file is 50K sized (not 4K aligned), and fsx polluted the
range beyond EOF through memory mapped write.
And since memory mapped write is page based, and our page size is
larger than block size, the page range [0, 64K) covere blocks beyond
EOF.
Those polluted range will not be written back, but will still affect
our page cache.
Then some operation happens to expand the inode to size 64K.
In that case btrfs_truncate_block() is called to trim the block
[48K, 52K), and that block will be marked dirty for written back.
But the range [52K, 64K) is untouched at all, left the garbage
hanging there, triggering `fsx -e 1` failure.
Fix this case by force btrfs_truncate_block() to zeroing any involved
blocks. (Meanwhile still only one block [48K, 52K) will be written
back)
2) EOF is polluted and the original size is block aligned so
btrfs_truncate_block() does nothing
0 32K 64K
| | |GGGGGGGGGGGG|
52K EOF
Mostly the same as case 1, but this time since the inode size is
block aligned, btrfs_truncate_block() will do nothing.
Leaving the garbage range [52K, 64K) untouched and fail `fsx -e 1`
runs.
Fix this case by force btrfs_truncate_block() to zeroing any involved
blocks when the btrfs is subpage and the range is aligned.
This will not cause any new dirty blocks, but purely zeroing out EOF
to pass `fsx -e 1` runs.
Qu Wenruo (2):
btrfs: make btrfs_truncate_block() to zero involved blocks in a folio
btrfs: make btrfs_truncate_block() zero folio range for certain
subpage corner cases
fs/btrfs/btrfs_inode.h | 10 ++-
fs/btrfs/file.c | 33 ++++++---
fs/btrfs/inode.c | 148 ++++++++++++++++++++++++++++++++++-------
3 files changed, 155 insertions(+), 36 deletions(-)
--
2.49.0
next reply other threads:[~2025-04-11 5:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 5:13 Qu Wenruo [this message]
2025-04-11 5:14 ` [PATCH 1/2] btrfs: make btrfs_truncate_block() to zero involved blocks in a folio Qu Wenruo
2025-04-11 7:02 ` Qu Wenruo
2025-04-11 5:14 ` [PATCH 2/2] btrfs: make btrfs_truncate_block() zero folio range for certain subpage corner cases Qu Wenruo
2025-04-12 5:12 ` kernel test robot
2025-04-12 5:54 ` kernel test robot
2025-04-12 18:35 ` Andy Shevchenko
2025-04-14 1:20 ` Qu Wenruo
2025-04-14 3:37 ` Qu Wenruo
2025-04-14 10:40 ` Andy Shevchenko
2025-04-15 18:18 ` David Sterba
2025-04-15 18:21 ` Andy Shevchenko
2025-04-15 23:57 ` Qu Wenruo
2025-04-16 5:57 ` Andy Shevchenko
2025-04-16 8:28 ` David Sterba
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=cover.1744344865.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox