Re: Panic: cache_vop_rename: lingering negative entry
Jan Martin Mikkelsen <[email protected]>
| Newsgroups | gmane.os.freebsd.current |
|---|---|
| Message-ID | <[email protected]> |
> On 7 Apr 2026, at 20:20, Jan Martin Mikkelsen <[email protected]> wrote: > > On 7 Apr 2026, at 18:53, Konstantin Belousov <[email protected]> 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. Jan M.