[PATCH 0/2] btrfs: btrfs_get_extent() cleanup

[Qu Wenruo <wqu@suse.com>]

There are some small but weird behavior in btrfs_get_extent() for inline
extent handling

- Resetting em members only for inline extent read

  If btrfs_get_extent() is called with @page (aka, for file read path),
  it will reset @em members even it's already updated by
  btrfs_extent_item_to_extent_map()

  The behavior itself is no longer needed as tree-checker has ensured
  inline extents are only valid if they have 0 file offset.

  Thus this means, in that path, @extent_offset must be 0, and a lot of
  calculations can be simplified and the em member reset is unnecessary.

- Unnecessarily complex handling for inline extent read

  The truth is, since inline extents can only exist at file offset 0, we
  don't need such complex calculation at all.

- Unnecessary argument for btrfs_extent_item_to_extent_map()

- Unnecessarily complex selftest for btrfs_get_extent()
  It has an inline extent at file offset 5, which is no longer valid.

The root cause is, the old code just assumes we can have inline extents
at non-zero file offset.

The patchset will replace those complex code, with just ASSERT()s, and
use much cleaner code to implement the same behavior, and also to update
the selftest to reflect the modern behavior.

Qu Wenruo (2):
  btrfs: refactor the inline extent read code inside btrfs_get_extent()
  btrfs: selftests: remove impossible inline extent at non-zero file
    offset

 fs/btrfs/ctree.h             |  1 -
 fs/btrfs/extent_map.c        |  7 +++
 fs/btrfs/file-item.c         |  6 +--
 fs/btrfs/inode.c             | 93 +++++++++++++++++++++---------------
 fs/btrfs/ioctl.c             |  2 +-
 fs/btrfs/tests/inode-tests.c | 56 +++++++---------------
 6 files changed, 82 insertions(+), 83 deletions(-)

-- 
2.37.3