Re: [PATCH] hfs: avoid reusing occupied CNIDs after deletion

[Viacheslav Dubeyko <slava@dubeyko.com>]

Hi Hengyu,

On Thu, 2026-10-15 at 22:31 -0400, Hengyu Liang wrote:
> Hi Slava,
> 
> On Thu, Oct 15, 2026 at 12:58:14PM -0700, Viacheslav Dubeyko wrote:
> > (1) The goal of hfs_correct_next_unused_CNID() was to fix the
> > volume
> > corruption issue. Have you run hfs.fsck tool to check that volume
> > is
> > valid (not corrupted) after your fix?
> 
> Thanks for pointing this out. I have now run the additional checks on
> v7.3-rc6 with this patch, using fsck.hfs 540.1-Linux:
> 
> - All 14 normal-volume images from the original tests passed
>   fsck.hfs -fn after unmount. This includes the reproducer, CNID
> holes,
>   missing optional file threads, concurrent operations, and reordered
>   leaf node numbers. The checker did not modify the images.
> 
> > (2) Have you run xfstests (especially, generic/736) with your fix?
> > Because, the patch had goal to fix the generic/736 failure:
> 
> - On a freshly formatted 64 MiB HFS volume, I ran:
> 
>     ./check -i 10 generic/736
> 
>   All 10 iterations passed, including the filesystem checks after
> each
>   iteration, with FSCK_OPTIONS="-fn". A separate fsck.hfs -fn after
>   the run also passed. There was no "invalid MDB drNxtCNID" error.
>   The unpatched v7.3-rc6 kernel also passed these 10 iterations.
> 
> - I repeated the minimal reproducer on a separate fresh volume. The
>   first creation of c failed with EEXIST without the patch and
> succeeded
>   with it. The surviving file's CNID and contents were unchanged, and
>   the patched volume passed fsck.hfs -fn after unmount.

Sounds great! Let me take a look into the code.

> 
> For completeness, I initially ran generic/736 on a 256 MiB HFS
> volume.
> The test body completed, but the final fsck reported:
> 
>     Invalid map node linkage
>     (4, 2048)
> 
> I reproduced the same failure on unpatched v7.3-rc6 with the same
> volume
> size and tools. The catalog had 6129 nodes, while its header map and
> single map node covered only 5984 nodes. I then used fresh 64 MiB
> volumes
> for the runs above; their filesystem checks passed without repair.

It looks that we have enough issues yet for the fix.

Thanks,
Slava.

> 
> No KASAN report or kernel BUG/WARNING was observed during these runs.
> 
> Thanks,
> Hengyu