> On Jan 4, 2023, at 4:36 PM, Viacheslav Dubeyko <slava@xxxxxxxxxxx> wrote: > > Hi Arnd, > >> On Jan 4, 2023, at 2:33 PM, Arnd Bergmann <arnd@xxxxxxxx> 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/000000000000dbce4e05f170f289@xxxxxxxxxx/ >> > > 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.
