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
fs/btrfs/extent-tree.c | 32 +++---------
fs/btrfs/extent_io.c | 67 +++++++++++++++++++++---
fs/btrfs/tests/extent-io-tests.c | 89 ++++++++++++++++++++++++++++++++
3 files changed, 157 insertions(+), 31 deletions(-)
--
2.17.1
