Re: [bug report] btrfs: fix corrupt read due to bad offset of a compressed extent map

[Dan Carpenter <error27@gmail.com>]

On Mon, Jun 15, 2026 at 01:56:22PM +0100, Filipe Manana wrote:
> On Mon, Jun 15, 2026 at 1:47 PM Dan Carpenter <error27@gmail.com> wrote:
> >     957         /*
> >     958          * Try to add the extent map but with a search range of [140K, 144K),
> >     959          * this should succeed and adjust the extent map to the range
> >     960          * [128K, 144K), with a length of 16K and an offset of 20K.
> >     961          *
> >     962          * This simulates a scenario where in the subvolume tree of an inode we
> >     963          * have a compressed file extent item for the range [108K, 144K) and we
> >     964          * have an overlapping compressed extent map for the range [120K, 128K),
> >     965          * which was created by an encoded write, but its ordered extent was not
> >     966          * yet completed, so the subvolume tree doesn't have yet the file extent
> >     967          * item for that range - we only have the extent map in the inode's
> >     968          * extent map tree.
> >     969          */
> >     970         write_lock(&em_tree->lock);
> >     971         ret = btrfs_add_extent_mapping(inode, &em, SZ_1K * 140, SZ_4K);
> >     972         write_unlock(&em_tree->lock);
> >     973         btrfs_free_extent_map(em);
> >
> > This looks like btrfs_free_extent_map() frees "em".
> 
> Nop, false alarm.
> And that's because btrfs_add_extent_mapping() will increase the ref
> count of the extent map if it returns success (one ref for the tree).
> So until the extent map is removed from the tree, we can use the em
> after calling btrfs_free_extent_map().
>

Ah.  Thanks for taking a look...

regards,
dan carpenter