Re: Panic: cache_vop_rename: lingering negative entry

On Mon, Apr 13, 2026 at 07:12:32PM +0200, Jan Martin Mikkelsen wrote:
> 
> > On 7 Apr 2026, at 20:20, Jan Martin Mikkelsen <janm@transactionware.com> wrote:
> > 
> > On 7 Apr 2026, at 18:53, Konstantin Belousov <kib@freebsd.org> wrote:
> >> 
> >> On Tue, Apr 07, 2026 at 05:02:05PM +0200, Jan Martin Mikkelsen wrote:
> >>> Hi,
> >>> 
> >>> I am consistently getting the panic below while building lang/perl5.42. This is the command from the perl build that triggers the panic:
> >>> 
> >>> /usr/bin/strip /ports-work/usr/ports/lang/perl5.42/work/stage/usr/local/bin/perl5.42.0
> >>> 
> >>> CURRENT on aarch64, with a kernel from last week, also with a later one from the  weekend. A kernel from mid-January worked fine.
> >>> 
> >>> I can reproduce on demand, no parallelism in the build required.
> >>> 
> >>> Does this look familiar to anyone?
> >>> 
> >>> panic: cache_vop_rename: lingering negative entry
> >>> cpuid = 4
> >>> time = 1775410763
> >>> KDB: stack backtrace:
> >>> db_trace_self() at db_trace_self
> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> >>> vpanic() at vpanic+0x1a0
> >>> panic() at panic+0x48
> >>> cache_vop_rename() at cache_vop_rename+0xb0
> >>> zfs_do_rename() at zfs_do_rename+0xafc
> >>> zfs_freebsd_rename() at zfs_freebsd_rename+0x5c
> >>> VOP_RENAME_APV() at VOP_RENAME_APV+0x44
> >>> kern_renameat () at kern_renameat+0x574
> >>> do_el0_sync() at do_el0_sync+0x5f8
> >>> handle_el0_sync() at handle_el0_sync+0x4c
> >>> --- exception, esr 0x56000000
> >>> KDB: enter: panic
> >>> [ thread pid 81230 tid 101738 ]
> >>> Stopped at kdb_enter+0x48: str xzr, [x19, #3072]
> >> 
> >> Is it reproducable on UFS and/or tmpfs?
> > 
> > Successful completion (no panic) when the work directory is on UFS, and when the work directory is on tmpfs. I didn’t try multiple times, but it never works on ZFS.
> 
> The panic consistently reproduces on a ZFS filesystem with the properties  “utf8only=on” and "normalization=formD”.
> 
> A ZFS file system with “utf8only=off” and "normalization=none” works fine.
> 
> As far as I can see, strip makes a simple rename(2) call, and testing rename(2) works fine (as expected). Running the same strip command on the same files on a fresh system works fine.
> 
> The smallest reproducer I have at the moment is building lang/perl5.42.0 with a workdir on a ZFS filesystem enforcing UTF8.

I am now sure that the reason is that the options you used cause the same
inode to have more than one name (but not hardlinks).  I remember that
zfs had option to be case-insensitive, but I may mis-remember.

The solution, in any case, is to either stop using namecache when these
options are activated, or at least purge all cached entries that has the
given dst when the dst vnode is renamed or deleted.

Somebody who knows zfs would be needed to make the change.