syzbot: WARNING: possible recursive locking in hfsplus_find_init
https://syzkaller.appspot.com/bug?extid=f8ce6c197125ab9d72ce

This is the whole solution Slava asked for, in one series:

Patch 1 fixes the recursive tree_lock itself: hfsplus_ext_read_extent()
now refuses to look up an overflow extent for the extents overflow
file's own inode (it can never have one), and hfsplus_file_extend()
tests whether the fork actually has room before allocating blocks for
it, instead of allocating and undoing the allocation on failure.

Patch 2 addresses "how would we check the fork itself" and "how could
we check the forks of other b-trees", asked across the last few
rounds: hfsplus_check_fork() validates the eight fork extents of the
extents, catalog and attributes trees at hfs_btree_open() time,
following the severity split discussed -- first extent unusable ->
mount fails; a later extent corrupt (the syzbot image's case) -> open
read-only.

v3 -> v4:
 - hfsplus_file_extend() tests fork capacity before allocating instead
   of allocating and freeing on -ENOSPC (Slava)
 - added hfsplus_check_fork(), called from hfs_btree_open() for all
   three trees, with the mount-fail/read-only severity split (Slava)
 - hfsplus_reconfigure() and hfsplus_fill_super() check the resulting
   per-tree corrupt flag instead of re-deriving it on every remount

Nguyen Ngoc Thang (2):
  hfsplus: fix recursive tree_lock in hfsplus_file_extend()
  hfsplus: validate b-tree fork extents at mount time

 fs/hfsplus/btree.c      | 12 ++++++
 fs/hfsplus/extents.c    | 96 +++++++++++++++++++++++++++++++++++++++--
 fs/hfsplus/hfsplus_fs.h |  4 ++
 fs/hfsplus/super.c      |  9 ++++
 4 files changed, 117 insertions(+), 4 deletions(-)

-- 
2.43.0