From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/2] btrfs: fix inlined file extent items in data reloc
Date: Tue, 23 Jun 2026 21:07:13 +0930 [thread overview]
Message-ID: <cover.1782214614.git.wqu@suse.com> (raw)
[CHANGELOG]
v3:
- Use btrfs_is_data_reloc_root()
- Reword the cause analyze to avoid confusion
- Expand the [FIX] section to explain why disabling compression will
avoid inlined extents
v2:
- Add more explanation on why we can created inlined extents even if
relocation is preallocating space
- Add the fixes: tag since the behavior is caused by a specific commit
There is a syzbot report that an inlined file extent item in a data
reloc inode triggered a sanity check in get_new_location().
It turns out that we can create inlined file extents for data reloc
inodes in the first place after commit 3eaf5f082c4c ("btrfs: extract
inlined creation into a dedicated delalloc helper").
So the first patch will avoid compression for data reloc inodes first,
then the second patch to reject inlined file extent items in
get_new_location(), making the checks more robust.
Qu Wenruo (2):
btrfs: do not try compression for data reloc inodes
btrfs: reject inline file extents item in get_new_location()
fs/btrfs/btrfs_inode.h | 2 ++
fs/btrfs/relocation.c | 7 +++++++
2 files changed, 9 insertions(+)
--
2.54.0
next reply other threads:[~2026-06-23 11:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 11:37 Qu Wenruo [this message]
2026-06-23 11:37 ` [PATCH v3 1/2] btrfs: do not try compression for data reloc inodes Qu Wenruo
2026-06-23 11:37 ` [PATCH v3 2/2] btrfs: reject inline file extents item in get_new_location() Qu Wenruo
2026-06-23 12:16 ` [PATCH v3 0/2] btrfs: fix inlined file extent items in data reloc Filipe Manana
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.1782214614.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 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.