Re: [PATCH] btrfs: fix wrong block_start calculation for btrfs_drop_extent_map_range()

[Wang Yugui <wangyugui@e16-tech.com>]

Hi,

> [BUG]
> During my extent_map cleanup/refactor, with more than too strict sanity
> checks, extent-map-tests::test_case_7() would crash my extent_map sanity
> checks.
> 
> The problem is, after btrfs_drop_extent_map_range(), the resulted
> extent_map has a @block_start way too large.
> Meanwhile my btrfs_file_extent_item based members are returning a
> correct @disk_bytenr along with correct @offset.
> 
> The extent map layout looks like this:
> 
>      0        16K    32K       48K
>      | PINNED |      | Regular |
> 
> The regular em at [32K, 48K) also has 32K @block_start.
> 
> Then drop range [0, 36K), which should shrink the regular one to be
> [36K, 48K).
> However the @block_start is incorrect, we expect 32K + 4K, but got 52K.
> 
> [CAUSE]
> Inside btrfs_drop_extent_map_range() function, if we hit an extent_map
> that covers the target range but is still beyond it, we need to split
> that extent map into half:
> 
> 	|<-- drop range -->|
> 		 |<----- existing extent_map --->|
> 
> And if the extent map is not compressed, we need to forward
> extent_map::block_start by the difference between the end of drop range
> and the extent map start.
> 
> However in that particular case, the difference is calculated using
> (start + len - em->start).
> 
> The problem is @start can be modified if the drop range covers any
> pinned extent.
> 
> This leads to wrong calculation, and would be caught by my later
> extent_map sanity checks, which checks the em::block_start against
> btrfs_file_extent_item::disk_bytenr + btrfs_file_extent_item::offset.
> 
> And unfortunately this is going to cause data corruption, as the
> splitted em is pointing an incorrect location, can cause either
> unexpected read error or wild writes.
> 
> [FIX]
> Fix it by avoiding using @start completely, and use @end - em->start
> instead, which @end is exclusive bytenr number.
> 
> And update the test case to verify the @block_start to prevent such
> problem from happening.
> 
> CC: stable@vger.kernel.org # 6.7+
> Fixes: c962098ca4af ("btrfs: fix incorrect splitting in btrfs_drop_extent_map_range")
> Signed-off-by: Qu Wenruo <wqu@suse.com>

$ git describe --contains c962098ca4af
v6.5-rc7~4^2

so it should be
CC: stable@vger.kernel.org # 6.5+

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2024/04/08