[PATCH] hfsplus: fix recursive tree_lock in hfsplus_file_extend()

[ThangNN99]

hfs_bmap_reserve() calls hfsplus_file_extend() on tree->inode with
tree->tree_lock already held.  When the tree is the extents overflow
B-tree and its own fork already claims more blocks than its eight
fork extents describe, hfsplus_file_extend() calls
hfsplus_ext_read_extent() -> hfs_find_init() on that same tree,
taking tree_lock a second time (lockdep: "possible recursive locking
... &tree->tree_lock/1").

Per the HFS+ format the extents overflow file is fully described by
its eight fork extents, so this state only arises from a corrupted
image. hfsplus_get_block() already refuses it for lookups; do the
same when growing the file.

Reported-by: syzbot+f8ce6c197125ab9d72ce@xxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: ThangNN99 <ngocthang2710.1999@xxxxxxxxx>
---
 fs/hfsplus/extents.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
index eb7c11524d18..39920b51e08b 100644
--- a/fs/hfsplus/extents.c
+++ b/fs/hfsplus/extents.c
@@ -458,6 +458,15 @@ int hfsplus_file_extend(struct inode *inode, bool zeroout)
 	if (hip->alloc_blocks == hip->first_blocks)
 		goal = hfsplus_ext_lastblock(hip->first_extents);
 	else {
+		/*
+		 * The extents overflow file can't have overflow extents of
+		 * its own; growing it here would re-enter hfs_find_init()
+		 * on the extents tree, whose tree_lock is already held.
+		 */
+		if (inode->i_ino == HFSPLUS_EXT_CNID) {
+			res = -EIO;
+			goto out;
+		}
 		res = hfsplus_ext_read_extent(inode, hip->alloc_blocks);
 		if (res)
 			goto out;
-- 
2.43.0