Re: [PATCH 2/6] btrfs: fix raid stripe search missing entries at leaf boundaries

[David Sterba <dsterba@suse.cz>]

On Mon, Apr 13, 2026 at 02:52:33PM +0800, robbieko wrote:
> In btrfs_delete_raid_extent(), the search key uses offset=0. When the
> target stripe entry is the first item on a leaf, btrfs_search_slot()
> may land on the previous leaf and decrementing the slot from nritems
> still points to the wrong entry, causing the stripe extent to be
> silently missed.
> 
> Fix this by searching with offset=(u64)-1 instead. Since no real stripe
> entry has this offset, btrfs_search_slot() always returns 1 with the
> slot pointing past the last matching objectid entry. Then unconditionally
> decrement the slot with a proper slots[0]==0 early-exit check to handle
> the case where no matching entry exists.
> 
> Signed-off-by: robbieko <robbieko@synology.com>
> ---
>  fs/btrfs/raid-stripe-tree.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/raid-stripe-tree.c b/fs/btrfs/raid-stripe-tree.c
> index 5c519e161331..d35efe74aa1b 100644
> --- a/fs/btrfs/raid-stripe-tree.c
> +++ b/fs/btrfs/raid-stripe-tree.c
> @@ -98,14 +98,26 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle *trans, u64 start, u64 le
>  	while (1) {
>  		key.objectid = start;
>  		key.type = BTRFS_RAID_STRIPE_KEY;
> -		key.offset = 0;
> +		key.offset = (u64)-1;
>  
>  		ret = btrfs_search_slot(trans, stripe_root, &key, path, -1, 1);
>  		if (ret < 0)
>  			break;
>  
> -		if (path->slots[0] == btrfs_header_nritems(path->nodes[0]))
> -			path->slots[0]--;
> +		/*
> +		 * Search with offset=(u64)-1 ensures we land on the correct
> +		 * leaf even when the target entry is the first item on a leaf.
> +		 * Since no real entry has offset=(u64)-1, ret is always 1 and

This would be good to handle, not just assumed. A corruption or fuzzed
image inserting the unexpected key with offset will continue while it
should not. Handled as an EUCLEAN, like it's in many other places after
searching for tree items. I'm not sure if it's 100% covered everywhere
but this case fits the pattern.