Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode
From:   Viacheslav Dubeyko <slava@dubeyko.com>
In-Reply-To: <2575F983-D170-4B79-A6BA-912D4ED2CC73@dubeyko.com>
Date:   Wed, 4 Jan 2023 20:37:16 -0800
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        syzbot <syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        christian.brauner@ubuntu.com,
        Damien Le Moal <damien.lemoal@opensource.wdc.com>,
        Jeff Layton <jlayton@kernel.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs@googlegroups.com,
        Matthew Wilcox <willy@infradead.org>,
        ZhangPeng <zhangpeng362@huawei.com>,
        linux-m68k@lists.linux-m68k.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <46F233BB-E587-4F2B-AA62-898EB46C9DCE@dubeyko.com>
References: <000000000000dbce4e05f170f289@google.com>
 <5f45bb9a-5e00-48dd-82b0-46b19b1b98a3@app.fastmail.com>
 <CAHk-=wi8XyAUF9_z6-oa4Ava6PVZeE-=TVNcFK1puQHpOtqLLw@mail.gmail.com>
 <ab7a9477-ddc7-430f-b4ee-c67251e879b0@app.fastmail.com>
 <2575F983-D170-4B79-A6BA-912D4ED2CC73@dubeyko.com>
To:     Arnd Bergmann <arnd@arndb.de>
Precedence: bulk


> On Jan 4, 2023, at 4:36 PM, Viacheslav Dubeyko <slava@dubeyko.com> =
wrote:
>=20
> Hi Arnd,
>=20
>> On Jan 4, 2023, at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:

<skipped>

>>>=20
>>> Something like this ENTIRELY UNTESTED patch?
>>>=20
>>> Do we have anybody who looks at hfs?
>>=20
>> Adding Viacheslav Dubeyko to Cc, he's at least been reviewing
>> patches for HFS and HFS+ somewhat recently. The linux-m68k
>> list may have some users dual-booting old MacOS.
>>=20
>> Viacheslav, see the start of the thread at
>> https://lore.kernel.org/lkml/000000000000dbce4e05f170f289@google.com/
>>=20
>=20
> Let me take a look into the issue.
>=20

As far as I can see, I cannot reproduce the issue for newly created HFS =
volume
with simple operation of creation of several files of 4MB in size. The =
sync_fs
operation definitely calls hfs_write_inode() method. But I don't see =
such issue.

The hfs_write_inode() allocates struct hfs_find_data fd variable on =
stack
(fs/hfs/inode.c:426). The fd.entrylength is initialized in =
__hfs_brec_find()
(fs/hfs/bfind.c:100). Technically, fd->entrylength =3D len - keylen can =
introduce
overflow. But, such issue can take place for corrupted volume. Internal =
logic
error should result with returning error by hfs_brec_find =
(fs/hfs/inode.c:466):

if (hfs_brec_find(&fd))
     /* panic? */
     goto out;

And, finally, logic should end without going into the issue.

Also, as far as I can see, available volume in report (mount_0.gz) =
somehow corrupted already:

sudo losetup /dev/loop20 ./mount_0
sudo fsck.hfs -d /dev/loop20
** /dev/loop20
Using cacheBlockSize=3D32K cacheTotalBlock=3D1024 cacheSize=3D32768K.
** Checking HFS volume.
hfs_swap_BTNode: record #1 invalid offset (0xFFF8)
   Invalid node structure
(3, 0)
   Invalid B-tree node size
(3, 0)
** Volume check failed.
volume check failed with error 7=20
volume type is HFS=20
primary MDB is at block 2 0x02=20
alternate MDB is at block 62 0x3e=20
primary VHB is at block 0 0x00=20
alternate VHB is at block 0 0x00=20
sector size =3D 512 0x200=20
VolumeObject flags =3D 0x19=20
total sectors for volume =3D 64 0x40=20
total sectors for embedded volume =3D 0 0x00

So, HFS volume corruption had happened somehow earlier.
The reported issue is only a side effect of volume corruption.
The real issue of HFS volume corruption had taken place before.
And it was a silent issue somehow.

Finally, I don=E2=80=99t see any issue with WARN_ON() in =
fs/hfs/inode.c:489.
If we have some issue, then it could happen in b-tree logic or
HFS volume was corrupted somehow else. But available report doesn=E2=80=99=
t
provide any hint what could be wrong during testing.

Thanks,
Slava.