Received-SPF: pass (google.com: domain of linux-kernel+bounces-15299-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: [PATCH] hfs: fix deadlock in hfs_extend_file
From: Viacheslav Dubeyko <slava@dubeyko.com>
In-Reply-To: <tencent_8C1ACE487B4E6C302EE56D8C95C0E8E2EF0A@qq.com>
Date: Wed, 3 Jan 2024 12:03:31 +0300
Cc: syzbot+41a88b825a315aac2254@syzkaller.appspotmail.com,
 Linux FS Devel <linux-fsdevel@vger.kernel.org>,
 LKML <linux-kernel@vger.kernel.org>,
 syzkaller-bugs@googlegroups.com,
 willy@infradead.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A468D14-579A-4EDF-9AFE-32A51C7101F3@dubeyko.com>
References: <0000000000004efa57060def87be@google.com>
 <tencent_8C1ACE487B4E6C302EE56D8C95C0E8E2EF0A@qq.com>
To: Edward Adam Davis <eadavis@qq.com>


> On Jan 2, 2024, at 3:36 PM, Edward Adam Davis <eadavis@qq.com> wrote:
>=20
> [syz report]
> syz-executor279/5059 is trying to acquire lock:
> ffff888079c100f8 (&HFS_I(tree->inode)->extents_lock){+.+.}-{3:3}, at: =
hfs_extend_file+0xa2/0xb10 fs/hfs/extent.c:397
>=20
> but task is already holding lock:
> ffff888079c10778 (&HFS_I(tree->inode)->extents_lock){+.+.}-{3:3}, at: =
hfs_extend_file+0xa2/0xb10 fs/hfs/extent.c:397
>=20
> other info that might help us debug this:
> Possible unsafe locking scenario:
>=20
>       CPU0
>       ----
>  lock(&HFS_I(tree->inode)->extents_lock);
>  lock(&HFS_I(tree->inode)->extents_lock);
>=20
> *** DEADLOCK ***
> [Analysis]=20
> hfs_extend_file()->
>   hfs_ext_read_extent()->
>     __hfs_ext_cache_extent()->
>       __hfs_ext_write_extent()->
>         hfs_bmap_reserve()->
>           hfs_extend_file()->
>=20
> When an inode has both the HFS_FLG_EXT_DIRTY and HFS_FLG_EXT_NEW =
flags, it will
> enter the above loop and trigger a deadlock.
>=20
> [Fix]
> In hfs_ext_read_extent(), check if the above two flags exist =
simultaneously,=20
> and exit the subsequent process when the conditions are met.
>=20
> Reported-and-tested-by: =
syzbot+41a88b825a315aac2254@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> fs/hfs/extent.c | 4 ++++
> 1 file changed, 4 insertions(+)
>=20
> diff --git a/fs/hfs/extent.c b/fs/hfs/extent.c
> index 6d1878b99b30..1b02c7b6a10c 100644
> --- a/fs/hfs/extent.c
> +++ b/fs/hfs/extent.c
> @@ -197,6 +197,10 @@ static int hfs_ext_read_extent(struct inode =
*inode, u16 block)
> 	    block < HFS_I(inode)->cached_start + =
HFS_I(inode)->cached_blocks)
> 		return 0;
>=20
> +	if (HFS_I(inode)->flags & HFS_FLG_EXT_DIRTY &&=20
> +	    HFS_I(inode)->flags & HFS_FLG_EXT_NEW)=20
> +		return -ENOENT;
> +

I don=E2=80=99t think that fix can be so simple. It looks like the code =
requires significant
refactoring. Because, currently, it looks like bad recursion: =
hfs_extend_file() finally
calls hfs_extend_file(). And it smells really badly. Also, from the =
logical point of view,
hfs_ext_read_extent() method calls __hfs_ext_write_extent() that sounds =
like not
good logic. I believe we need more serious refactoring of =
hfs_extend_file() logic.

Potentially, hfs_extend_file() can check that we have HFS_FLG_EXT_DIRTY =
and
execute logic of write extent without calling himself again. But I =
haven=E2=80=99t clear picture
of necessary refactoring efforts yet.

Thanks,
Slava.