From: Qu Wenruo <wqu@suse.com>
To: Teng Liu <27rabbitlt@gmail.com>, linux-btrfs@vger.kernel.org
Cc: dsterba@suse.com, clm@fb.com, wqu@suse.co,
linux-kernel@vger.kernel.org,
syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.co,
syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] btrfs: replace BUG_ON() with error return in get_new_location()
Date: Mon, 27 Apr 2026 10:49:26 +0930 [thread overview]
Message-ID: <54f27c1a-eb99-43d0-bf57-9e99caf07cb5@suse.com> (raw)
In-Reply-To: <20260426201605.36626-1-27rabbitlt@gmail.com>
在 2026/4/27 05:46, Teng Liu 写道:
> In get_new_location(), BUG_ON() crashes the kernel if the looked up
> file extent item has any of offset, compression, encryption, or other
> encoding set. The data reloc inode this lookup targets is populated
> solely by relocation's own prealloc and writeback paths:
>
> - insert_prealloc_file_extent() memsets the stack item to 0 and only
> sets type/disk_bytenr/disk_num_bytes/num_bytes, so the four checked
> fields stay 0.
> - insert_ordered_extent_file_extent() copies oe->compress_type into
> file_extent compression, but the data reloc inode is created with
> BTRFS_INODE_NOCOMPRESS, so compress_type is always 0; encryption
> and other_encoding are reserved-and-zero per the comment in that
> function.
>
> So observing non-zero compression, encryption or other_encoding here
> should on-disk corruption. A malformed image can reach this code
> through a balance operation and panic the kernel.
>
> Replace the BUG_ON() with a return of -EUCLEAN, the established error
> code in fs/btrfs/relocation.c for filesystem corruption, and pair it
> with btrfs_print_leaf() and btrfs_err() as suggested by Qu allowing dmesg
> to log the necessary information. The caller in replace_file_extents()
> already handles errors from get_new_location() by breaking out of the loop
> without aborting the transaction, so no caller changes are needed.
>
> Reported-by: syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3e20d8f3d41bac5dc9a2
> Signed-off-by: Teng Liu <27rabbitlt@gmail.com>
> ---
> Changes in v2:
> - Pair the -EUCLEAN return with btrfs_print_leaf() and btrfs_err() so
> the offending leaf is dumped to dmesg, per Qu's review:
> https://lore.kernel.org/linux-btrfs/6c54901d-5e07-4c46-9553-997b28c93b86@suse.com/
> - Expand the changelog to argue why non-zero compression/encryption/
> other_encoding in the data reloc inode imply on-disk corruption
> rather than a kernel bug.
>
> fs/btrfs/relocation.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 1c42c5180bdd..bba28866df1c 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -814,6 +814,7 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr,
> u64 bytenr, u64 num_bytes)
> {
> struct btrfs_root *root = BTRFS_I(reloc_inode)->root;
> + struct btrfs_fs_info *fs_info = root->fs_info;
> BTRFS_PATH_AUTO_FREE(path);
> struct btrfs_file_extent_item *fi;
> struct extent_buffer *leaf;
> @@ -835,10 +836,16 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr,
> fi = btrfs_item_ptr(leaf, path->slots[0],
> struct btrfs_file_extent_item);
>
> - BUG_ON(btrfs_file_extent_offset(leaf, fi) ||
> - btrfs_file_extent_compression(leaf, fi) ||
> - btrfs_file_extent_encryption(leaf, fi) ||
> - btrfs_file_extent_other_encoding(leaf, fi));
> + if (unlikely(btrfs_file_extent_offset(leaf, fi) ||
> + btrfs_file_extent_compression(leaf, fi) ||
> + btrfs_file_extent_encryption(leaf, fi) ||
> + btrfs_file_extent_other_encoding(leaf, fi))) {
> + btrfs_print_leaf(leaf);
> + btrfs_err(fs_info,
> +"unexpected non-zero fields in file extent item for data reloc inode %llu offset %llu (offset/compression/encryption/other_encoding must all be 0)",
> + btrfs_ino(BTRFS_I(reloc_inode)), bytenr);
> + return -EUCLEAN;
This looks like exactly what we did in tree-checker.
And we have enough info to do this in tree-checker, the data reloc tree
has a fixed id and owner in extent buffer header.
What about moving this to tree-checker where we already have
check_extent_data_item().
Furthermore, if you move this check into tree-checker, it's better to
print the offset/compress/encryption/other_encoding values.
And remove the "must all be 0", just something like:
file_extent_err(leaf, slot,
"invalid members for data reloc tree, offset=%llu compress=%llu
encryption=%llu other_encoding=%llu",
...);
> + }
>
> if (num_bytes != btrfs_file_extent_disk_num_bytes(leaf, fi))
> return -EINVAL;
next prev parent reply other threads:[~2026-04-27 1:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-25 6:10 [PATCH] btrfs: replace BUG_ON() with error return in get_new_location() Teng Liu
2026-04-25 8:06 ` Qu Wenruo
2026-04-26 20:16 ` [PATCH v2] " Teng Liu
2026-04-27 1:19 ` Qu Wenruo [this message]
2026-04-27 13:50 ` David Sterba
2026-04-27 20:24 ` [PATCH v3] btrfs: validate data reloc tree file extent item members in tree-checker Teng Liu
2026-04-27 22:15 ` Qu Wenruo
2026-04-28 0:44 ` Qu Wenruo
2026-04-28 15:29 ` David Sterba
2026-04-28 9:03 ` Johannes Thumshirn
2026-05-03 15:35 ` Teng Liu
2026-05-03 22:36 ` Qu Wenruo
2026-05-13 11:35 ` [PATCH v4] btrfs: validate data reloc tree file extent item members Teng Liu
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=54f27c1a-eb99-43d0-bf57-9e99caf07cb5@suse.com \
--to=wqu@suse.com \
--cc=27rabbitlt@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.co \
--cc=syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.com \
--cc=wqu@suse.co \
/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.