[PATCH v2 0/2] btrfs: fix inlined file extent items in data reloc

[PATCH v2 0/2] btrfs: fix inlined file extent items in data reloc

[Qu Wenruo]

[CHANGELOG]
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 extent item in get_new_location()

 fs/btrfs/btrfs_inode.h | 2 ++
 fs/btrfs/relocation.c  | 7 +++++++
 2 files changed, 9 insertions(+)

-- 
2.54.0

[PATCH] btrfs: print-tree: print header owner as signed

[Qu Wenruo]

When dumpping a tree block, btrfs_header::owner is printed as
unsigned, which can result in numbers that are hard to read, e.g:

 BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607

For the above output, 18446744073709551607 is (s64)-9, the root id of data
reloc tree.

Despite those pre-defined root ids that are already negative, existing
subvolume trees will not have any negative values, as subvolume trees can
only utilize the lower 48 bits, so there will be no output change for
existing subvolumes, thus no extra confusion.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/print-tree.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index 87e60a2d4bd8..53e726119ca7 100644
--- a/fs/btrfs/print-tree.c
+++ b/fs/btrfs/print-tree.c
@@ -449,9 +449,9 @@ void btrfs_print_leaf(const struct extent_buffer *l)
 	nr = btrfs_header_nritems(l);
 
 	btrfs_info(fs_info,
-		   "leaf %llu gen %llu total ptrs %d free space %d owner %llu",
+		   "leaf %llu gen %llu total ptrs %d free space %d owner %lld",
 		   btrfs_header_bytenr(l), btrfs_header_generation(l), nr,
-		   btrfs_leaf_free_space(l), btrfs_header_owner(l));
+		   btrfs_leaf_free_space(l), (s64)btrfs_header_owner(l));
 	print_eb_refs_lock(l);
 	for (i = 0 ; i < nr ; i++) {
 		char key_buf[KEY_TYPE_BUF_SIZE];
@@ -600,10 +600,10 @@ void btrfs_print_tree(const struct extent_buffer *c, bool follow)
 		return;
 	}
 	btrfs_info(fs_info,
-		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %llu",
+		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %lld",
 		   btrfs_header_bytenr(c), level, btrfs_header_generation(c),
 		   nr, (u32)BTRFS_NODEPTRS_PER_BLOCK(fs_info) - nr,
-		   btrfs_header_owner(c));
+		   (s64)btrfs_header_owner(c));
 	print_eb_refs_lock(c);
 	for (i = 0; i < nr; i++) {
 		btrfs_node_key_to_cpu(c, &key, i);
-- 
2.54.0

Re: [PATCH] btrfs: print-tree: print header owner as signed

[Filipe Manana]

On Sun, Jun 21, 2026 at 10:12 AM Qu Wenruo <wqu@suse.com> wrote:
>
> When dumpping a tree block, btrfs_header::owner is printed as
> unsigned, which can result in numbers that are hard to read, e.g:
>
>  BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607
>
> For the above output, 18446744073709551607 is (s64)-9, the root id of data
> reloc tree.
>
> Despite those pre-defined root ids that are already negative, existing
> subvolume trees will not have any negative values, as subvolume trees can
> only utilize the lower 48 bits, so there will be no output change for
> existing subvolumes, thus no extra confusion.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Reviewed-by: Filipe Manana <fdmanana@suse.com>

Thanks.

> ---
>  fs/btrfs/print-tree.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
> index 87e60a2d4bd8..53e726119ca7 100644
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> @@ -449,9 +449,9 @@ void btrfs_print_leaf(const struct extent_buffer *l)
>         nr = btrfs_header_nritems(l);
>
>         btrfs_info(fs_info,
> -                  "leaf %llu gen %llu total ptrs %d free space %d owner %llu",
> +                  "leaf %llu gen %llu total ptrs %d free space %d owner %lld",
>                    btrfs_header_bytenr(l), btrfs_header_generation(l), nr,
> -                  btrfs_leaf_free_space(l), btrfs_header_owner(l));
> +                  btrfs_leaf_free_space(l), (s64)btrfs_header_owner(l));
>         print_eb_refs_lock(l);
>         for (i = 0 ; i < nr ; i++) {
>                 char key_buf[KEY_TYPE_BUF_SIZE];
> @@ -600,10 +600,10 @@ void btrfs_print_tree(const struct extent_buffer *c, bool follow)
>                 return;
>         }
>         btrfs_info(fs_info,
> -                  "node %llu level %d gen %llu total ptrs %d free spc %u owner %llu",
> +                  "node %llu level %d gen %llu total ptrs %d free spc %u owner %lld",
>                    btrfs_header_bytenr(c), level, btrfs_header_generation(c),
>                    nr, (u32)BTRFS_NODEPTRS_PER_BLOCK(fs_info) - nr,
> -                  btrfs_header_owner(c));
> +                  (s64)btrfs_header_owner(c));
>         print_eb_refs_lock(c);
>         for (i = 0; i < nr; i++) {
>                 btrfs_node_key_to_cpu(c, &key, i);
> --
> 2.54.0
>
>

Re: [PATCH] btrfs: print-tree: print header owner as signed

[sun k]

Looks good.

Reviewed-by: Sun YangKai <sunk67188@gmail.com>

BTW, this reminds me the print-tree result of dir items that points to a
subvol, which currently looks like this:

item 4 key (256 DIR_ITEM 224155391) itemoff 15967 itemsize 48
                location key (43123 ROOT_ITEM 18446744073709551615) type DIR
                transid 896627 data_len 0 name_len 18
                name: home.20260621T2000

And I wonder if we can also print the location key's offset field as s64
to make it easier to read.

Thanks,
Sun YangKai


On 2026/6/21 17:11, Qu Wenruo wrote:
> When dumpping a tree block, btrfs_header::owner is printed as
> unsigned, which can result in numbers that are hard to read, e.g:
>
>   BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607
>
> For the above output, 18446744073709551607 is (s64)-9, the root id of data
> reloc tree.
>
> Despite those pre-defined root ids that are already negative, existing
> subvolume trees will not have any negative values, as subvolume trees can
> only utilize the lower 48 bits, so there will be no output change for
> existing subvolumes, thus no extra confusion.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   fs/btrfs/print-tree.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
> index 87e60a2d4bd8..53e726119ca7 100644
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> @@ -449,9 +449,9 @@ void btrfs_print_leaf(const struct extent_buffer *l)
>       nr = btrfs_header_nritems(l);
>
>       btrfs_info(fs_info,
> -                "leaf %llu gen %llu total ptrs %d free space %d owner %llu",
> +                "leaf %llu gen %llu total ptrs %d free space %d owner %lld",
>                  btrfs_header_bytenr(l), btrfs_header_generation(l), nr,
> -                btrfs_leaf_free_space(l), btrfs_header_owner(l));
> +                btrfs_leaf_free_space(l), (s64)btrfs_header_owner(l));
>       print_eb_refs_lock(l);
>       for (i = 0 ; i < nr ; i++) {
>               char key_buf[KEY_TYPE_BUF_SIZE];
> @@ -600,10 +600,10 @@ void btrfs_print_tree(const struct extent_buffer *c, bool follow)
>               return;
>       }
>       btrfs_info(fs_info,
> -                "node %llu level %d gen %llu total ptrs %d free spc %u owner %llu",
> +                "node %llu level %d gen %llu total ptrs %d free spc %u owner %lld",
>                  btrfs_header_bytenr(c), level, btrfs_header_generation(c),
>                  nr, (u32)BTRFS_NODEPTRS_PER_BLOCK(fs_info) - nr,
> -                btrfs_header_owner(c));
> +                (s64)btrfs_header_owner(c));
>       print_eb_refs_lock(c);
>       for (i = 0; i < nr; i++) {
>               btrfs_node_key_to_cpu(c, &key, i);

Re: [PATCH] btrfs: print-tree: print header owner as signed

[David Sterba]

On Mon, Jun 22, 2026 at 08:00:06PM +0800, sun k wrote:
> Looks good.
> 
> Reviewed-by: Sun YangKai <sunk67188@gmail.com>
> 
> BTW, this reminds me the print-tree result of dir items that points to a
> subvol, which currently looks like this:
> 
> item 4 key (256 DIR_ITEM 224155391) itemoff 15967 itemsize 48
>                 location key (43123 ROOT_ITEM 18446744073709551615) type DIR
>                 transid 896627 data_len 0 name_len 18
>                 name: home.20260621T2000
> 
> And I wonder if we can also print the location key's offset field as s64
> to make it easier to read.

It should be consistent for the ROOT_ITEM and references and we can
actually print the name of the tree, as is done in dump-tree output.

Re: [PATCH] btrfs: print-tree: print header owner as signed

[sun k]

On Tue, Jun 23, 2026 at 8:08 AM David Sterba <dsterba@suse.cz> wrote:
>
> On Mon, Jun 22, 2026 at 08:00:06PM +0800, sun k wrote:
> > Looks good.
> >
> > Reviewed-by: Sun YangKai <sunk67188@gmail.com>
> >
> > BTW, this reminds me the print-tree result of dir items that points to a
> > subvol, which currently looks like this:
> >
> > item 4 key (256 DIR_ITEM 224155391) itemoff 15967 itemsize 48
> >                 location key (43123 ROOT_ITEM 18446744073709551615) type DIR
> >                 transid 896627 data_len 0 name_len 18
> >                 name: home.20260621T2000
> >
> > And I wonder if we can also print the location key's offset field as s64
> > to make it easier to read.
>
> It should be consistent for the ROOT_ITEM and references and we can
> actually print the name of the tree, as is done in dump-tree output.

Hi David,

I'm not sure if I follow you here. The offset field of a dir item
which points to a subvol is
a little special. Its offset field will always be `0` for subvolume or
`-1` for snapshot instead
of other values. While in root tree, the offset field will always be
`0` for subvol and `generation`
for snapshot. So take this as an example, when location key is (43123
ROOT_ITEM -1) in dir item,
there's no such an item in root tree, but something like (43123
ROOT_ITEM 8750971) instead.
8750971 is the generation when the snapshot is created. So I'm not
sure what is `the name of the tree`.

BTW, it might be a little off-topic: IMO this design is used to search
the last snapshot when the
object ids of multiple snapshots of the same subvol, which are created
in different generations,
is shared. But we never allow this and always allocate a new object id
for snapshots in reality.
I wonder if we can use this to make snapshots really snapshots instead
of a read-only subvol.

Thanks,
Sun YangKai

[PATCH] btrfs: print-tree: print header owner as signed

[Qu Wenruo]

When dumpping a tree block, btrfs_header::owner is printed as
unsigned, which can result in numbers that are hard to read, e.g:

 BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607

For the above output, 18446744073709551607 is (s64)-9, the root id of data
reloc tree.

Despite those pre-defined root ids that are already negative, existing
subvolume trees will not have any negative values, as subvolume trees can
only utilize the lower 48 bits, so there will be no output change for
existing subvolumes, thus no extra confusion.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/print-tree.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index 87e60a2d4bd8..53e726119ca7 100644
--- a/fs/btrfs/print-tree.c
+++ b/fs/btrfs/print-tree.c
@@ -449,9 +449,9 @@ void btrfs_print_leaf(const struct extent_buffer *l)
 	nr = btrfs_header_nritems(l);
 
 	btrfs_info(fs_info,
-		   "leaf %llu gen %llu total ptrs %d free space %d owner %llu",
+		   "leaf %llu gen %llu total ptrs %d free space %d owner %lld",
 		   btrfs_header_bytenr(l), btrfs_header_generation(l), nr,
-		   btrfs_leaf_free_space(l), btrfs_header_owner(l));
+		   btrfs_leaf_free_space(l), (s64)btrfs_header_owner(l));
 	print_eb_refs_lock(l);
 	for (i = 0 ; i < nr ; i++) {
 		char key_buf[KEY_TYPE_BUF_SIZE];
@@ -600,10 +600,10 @@ void btrfs_print_tree(const struct extent_buffer *c, bool follow)
 		return;
 	}
 	btrfs_info(fs_info,
-		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %llu",
+		   "node %llu level %d gen %llu total ptrs %d free spc %u owner %lld",
 		   btrfs_header_bytenr(c), level, btrfs_header_generation(c),
 		   nr, (u32)BTRFS_NODEPTRS_PER_BLOCK(fs_info) - nr,
-		   btrfs_header_owner(c));
+		   (s64)btrfs_header_owner(c));
 	print_eb_refs_lock(c);
 	for (i = 0; i < nr; i++) {
 		btrfs_node_key_to_cpu(c, &key, i);
-- 
2.54.0

[PATCH v2 1/2] btrfs: do not try compression for data reloc inodes

[Qu Wenruo]

[BUG]
There is a syzbot report that the check inside get_new_location()
triggered:

 BTRFS info (device loop0): found 31 extents, stage: move data extents
 BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607
        item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160
                inode generation 5 transid 0 size 0 nbytes 0
                block group 0 mode 40755 links 1 uid 0 gid 0
                rdev 0 sequence 0 flags 0x0
                atime 1669132761.0
                ctime 1669132761.0
                mtime 1669132761.0
                otime 0.0
        item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12
                index 0 name_len 2
        item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160
                inode generation 1 transid 16 size 733184 nbytes 106496
                block group 0 mode 100600 links 0 uid 0 gid 0
                rdev 0 sequence 24 flags 0x18
        item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68
                generation 16 type 0
                inline extent data size 47 ram_bytes 4096 compression 1
 [...]
        item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0
 BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337
 ------------[ cut here ]------------
 btrfs_abort_should_print_stack(__error)

[CAUSE]
The above dump tree shows the first file extent item is inlined, which
should make no sense for data reloc inodes, as such inodes are just
representing where the data extents are in the relocation destination chunk.

However the relocation path is just preallocate space for each block,
then dirty them, cluster by cluster.
It's possible to have a single block at the beginning of the block
group, and no other block in the same cluster.

Then relocation will preallocate a file extent for that block, dirty the first block.
Then memory pressure forces the data reloc inode to be written back, before
any other blocks being dirtied/allocated.

Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated
delalloc helper") changed the timing of delalloc, before that commit we
always try NOCOW first, so that dirtied block will be written back into
the preallocated space.

But with that commit, we always try inline first, and since compression
is forced, we try compressing the first block, and then inline the
compressed data, resulting in the above inlined file extent in data
reloc tree.

Then the check in get_new_location() will check the file offset, without
checking if the file extent is inlined or not, resulting the above
failure.

[FIX]
Do not allow compression for data reloc inodes in the first place.

Reported-by: syzbot+d950c6ba09b79f6e1864@syzkaller.appspotmail.com
Link: https://lore.kernel.org/linux-btrfs/6a373dc5.764cf64f.168fbe.0001.GAE@google.com/
Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper")
Cc: stable@vger.kernel.org
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/btrfs_inode.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index d5d81f9546c3..fff72f6cc1e8 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -476,6 +476,8 @@ static inline bool btrfs_inode_can_compress(const struct btrfs_inode *inode)
 	if (inode->flags & BTRFS_INODE_NODATACOW ||
 	    inode->flags & BTRFS_INODE_NODATASUM)
 		return false;
+	if (btrfs_root_id(inode->root) == BTRFS_DATA_RELOC_TREE_OBJECTID)
+		return false;
 	return true;
 }
 
-- 
2.54.0

[PATCH v2 2/2] btrfs: reject inline file extent item in get_new_location()

[Qu Wenruo]

Commit a6908f88c9da ("btrfs: validate data reloc tree file extent item
members") introduced extra checks on file extent items for data reloc
inodes, but it checks file extent offset without checking if the file
extent is inlined.

This can lead to either false alerts (as the offset member is inside the
inlined data) or even read beyond the item range.

This has already triggered a warning in a syzbot report.
Although the root fix is to avoid compression for data reloc inodes, for
the sake of consistency, reject inlined file extents first.

Fixes: a6908f88c9da ("btrfs: validate data reloc tree file extent item members")
Cc: stable@vger.kernel.org
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/relocation.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index e1dd9939f4f1..f5fac0e34494 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -893,6 +893,13 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr,
 	leaf = path->nodes[0];
 	fi = btrfs_item_ptr(leaf, path->slots[0],
 			    struct btrfs_file_extent_item);
+	if (unlikely(btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)) {
+		btrfs_print_leaf(leaf);
+		btrfs_err(fs_info,
+	"unexpected inline file extent item for data reloc inode %llu key offset %llu",
+			  btrfs_ino(BTRFS_I(reloc_inode)), bytenr);
+		return -EUCLEAN;
+	}
 
 	/*
 	 * The cluster-boundary key searched above is always written by
-- 
2.54.0