]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
btrfs: don't skip remaining extrefs if dir not found during log replay
authorFilipe Manana <fdmanana@suse.com>
Fri, 11 Jul 2025 19:48:23 +0000 (20:48 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 20 Aug 2025 16:36:31 +0000 (18:36 +0200)
commit672673af7a78af8269bb1899d9f5a376d8b9fc6f
treed6df83d72d80da6864dc72c7de0beedaff176562
parent452b9a1e8a2a8681d865afda9d75e944405e482b
btrfs: don't skip remaining extrefs if dir not found during log replay

commit 24e066ded45b8147b79c7455ac43a5bff7b5f378 upstream.

During log replay, at add_inode_ref(), if we have an extref item that
contains multiple extrefs and one of them points to a directory that does
not exist in the subvolume tree, we are supposed to ignore it and process
the remaining extrefs encoded in the extref item, since each extref can
point to a different parent inode. However when that happens we just
return from the function and ignore the remaining extrefs.

The problem has been around since extrefs were introduced, in commit
f186373fef00 ("btrfs: extended inode refs"), but it's hard to hit in
practice because getting extref items encoding multiple extref requires
getting a hash collision when computing the offset of the extref's
key. The offset if computed like this:

  key.offset = btrfs_extref_hash(dir_ino, name->name, name->len);

and btrfs_extref_hash() is just a wrapper around crc32c().

Fix this by moving to next iteration of the loop when we don't find
the parent directory that an extref points to.

Fixes: f186373fef00 ("btrfs: extended inode refs")
CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/tree-log.c