Viacheslav Dubeyko
unread,Jan 5, 2023, 5:54:40 AM1/5/23Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Arnd Bergmann, Linus Torvalds, syzbot, Andrew Morton, christia...@ubuntu.com, Damien Le Moal, Jeff Layton, Linux FS Devel, LKML, syzkall...@googlegroups.com, Matthew Wilcox, ZhangPeng, linux...@lists.linux-m68k.org
> On Jan 4, 2023, at 4:36 PM, Viacheslav Dubeyko <
sl...@dubeyko.com> wrote:
>
> Hi Arnd,
>
>> On Jan 4, 2023, at 2:33 PM, Arnd Bergmann <
ar...@arndb.de> wrote:
<skipped>
>>>
>>> Something like this ENTIRELY UNTESTED patch?
>>>
>>> Do we have anybody who looks at hfs?
>>
>> 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.
>>
>> Viacheslav, see the start of the thread at
>>
https://lore.kernel.org/lkml/000000000000db...@google.com/
>>
>
> Let me take a look into the issue.
>
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 = 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=32K cacheTotalBlock=1024 cacheSize=32768K.
** 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
volume type is HFS
primary MDB is at block 2 0x02
alternate MDB is at block 62 0x3e
primary VHB is at block 0 0x00
alternate VHB is at block 0 0x00
sector size = 512 0x200
VolumeObject flags = 0x19
total sectors for volume = 64 0x40
total sectors for embedded volume = 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’t 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’t
provide any hint what could be wrong during testing.
Thanks,
Slava.