On Mon, Jun 03, 2019 at 01:05:58PM +0300, Nikolay Borisov wrote: > Qu reported beyond EOD (end of device) access with latest FITRIM improvements > that were merged. Further testing also showed that if ranged FITRIM request > is > sent it's possible to cause u64 overflow which in turn cause calculations to > go off rail in btrfs_issue_discard (because it's called with start and len > as (u64)-1) and trim used data. > > This patchset aims to rectify this by: > > 1. Documenting the internal __etree_search since due to the rather high > number of output parameters it can be a bit confusing as to what the > invariants > are. Due to this I got initially confused about possible return values on > boundary conditions. (Patch 1) > > 2. Remove ranged support in btrfs_trim_free_extents - having range support in > btrfs_trim_free_extent is problematic because it's interpreted in device > physical > space whilst range values from userspace should always be interpreted in > logical space. (Patch 2) > > 3. Change slightly the semantics of find_first_clear_extent_bit to return the > range that contains the passed address or in case no such range exists the > next one, document the function and finally add tests (Patch 3 preps > btrfs_trim_free_extents to handle the change semantics and Patch 4 change > the semantics). > > This has been fully tested with xfstest and no regressions were found. > > Nikolay Borisov (4): > btrfs: Document __etree_search > btrfs: Always trim all unallocated space in btrfs_trim_free_extents > btrfs: Skip first megabyte on device when trimming > btrfs: Don't trim returned range based on input value in > find_first_clear_extent_bit
Added to misc-next, with some adjustments and 2/4 will go to the next 5.2-rc. Thanks.
