hfsplus: remove mutex_lock check in hfsplus_free_extents

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: remove mutex_lock check in hfsplus_free_extents

Syzbot reported an issue in hfsplus filesystem:

------------[ cut here ]------------

WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346

hfsplus_free_extents+0x700/0xad0

Call Trace:

<TASK>

hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606

hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56

cont_expand_zero fs/buffer.c:2383 [inline]

cont_write_begin+0x2cf/0x860 fs/buffer.c:2446

hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52

generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347

hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263

notify_change+0xe38/0x10f0 fs/attr.c:420

do_truncate+0x1fb/0x2e0 fs/open.c:65

do_sys_ftruncate+0x2eb/0x380 fs/open.c:193

do_syscall_x64 arch/x86/entry/common.c:50 [inline]

do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80

entry_SYSCALL_64_after_hwframe+0x63/0xcd

To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock

on file truncation") unlock extree before hfsplus_free_extents(),

and add check wheather extree is locked in hfsplus_free_extents().

However, when operations such as hfsplus_file_release,

hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed

concurrently in different files, it is very likely to trigger the

WARN_ON, which will lead syzbot and xfstest to consider it as an

abnormality.

The comment above this warning also describes one of the easy

triggering situations, which can easily trigger and cause

xfstest&syzbot to report errors.

[task A] [task B]

->hfsplus_file_release

->hfsplus_file_truncate

->hfs_find_init

->mutex_lock

->mutex_unlock

->hfsplus_write_begin

->hfsplus_get_block

->hfsplus_file_extend

->hfsplus_ext_read_extent

->hfs_find_init

->mutex_lock

->hfsplus_free_extents

WARN_ON(mutex_is_locked) !!!

Several threads could try to lock the shared extents tree.

And warning can be triggered in one thread when another thread

has locked the tree. This is the wrong behavior of the code and

we need to remove the warning.