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

[Viacheslav Dubeyko]

On Sun, 2026-09-06 at 22:49 +0700, ThangNN99 wrote:
> 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").

Could you please explain the use-case or workload that is trying to
claim more blocks that fork can include for Extents Overflow file?
Could you please share the call trace for the issue?

Thanks,
Slava.

> 
> 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;