Re: [PATCH 6.6.y] btrfs: don't skip remaining extrefs if dir not found during log replay

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Aug 18, 2025 at 08:14:51PM -0400, Sasha Levin wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> [ Upstream commit 24e066ded45b8147b79c7455ac43a5bff7b5f378 ]
> 
> 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: Sasha Levin <sashal@kernel.org>
> ---
>  fs/btrfs/tree-log.c | 25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)

This isn't applying to the 6.6.y queue right now:
	patching file fs/btrfs/tree-log.c
	Hunk #1 succeeded at 1446 (offset 1 line).
	Hunk #2 FAILED at 1458.
	Hunk #3 succeeded at 1512 (offset 10 lines).
	1 out of 3 hunks FAILED -- rejects in file fs/btrfs/tree-log.c

Can you rebase and resend?

thanks,

greg k-h