Re: Panic: cache_vop_rename: lingering negative entry

On Tue, Apr 14, 2026 at 2:53 AM Konstantin Belousov <kib@freebsd.org> wrote:
>
> On Tue, Apr 14, 2026 at 11:45:08AM +0200, Jan Martin Mikkelsen wrote:
> >
> > > On 13 Apr 2026, at 22:13, Konstantin Belousov <kib@freebsd.org> wrote:
> > >
> > > 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.
> >
> > I had a look at the ZFS source, and found this:
> >
> >         /*
> >          * Only use the name cache if we are looking for a
> >          * name on a file system that does not require normalization
> >          * or case folding.  We can also look there if we happen to be
> >          * on a non-normalizing, mixed sensitivity file system IF we
> >          * are looking for the exact name (which is always the case on
> >          * FreeBSD).
> >          */
> >         zfsvfs->z_use_namecache = !zfsvfs->z_norm ||
> >             ((zfsvfs->z_case == ZFS_CASE_MIXED) &&
> >             !(zfsvfs->z_norm & ~U8_TEXTPREP_TOUPPER));
> >
> >
> > The call to cache_vop_rename() which causes the panic is not protected by an “if (zfsvfs->z_use_namecache)”, unlike the rest of the code that uses that to decide whether or not to use the namecache.
> >
> > Elsewhere in zfs_vnops_os.c, there is another call to a cache_vop* function, which is protected by a test:
> >
> >         if (zfsvfs->z_use_namecache)
> >                 cache_vop_rmdir(dvp, vp);
> >
> > It seems to me that this patch could resolve the problem. Does this seem reasonable?
> >
> > --- a/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c    2026-03-28 20:55:06.000000000 1100
> > +++ b/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c    2026-03-28 20:55:06.000000000 1100
> > @@ -3524,7 +3524,7 @@
> >                                   ZRENAMING, NULL));
> >                       }
> >               }
> > -             if (error == 0) {
> > +             if (error == 0 && zfsvfs->z_use_namecache) {
> >                       cache_vop_rename(sdvp, *svpp, tdvp, *tvpp, scnp, tcnp);
> >               }
> >       }
> >
>
> Yes, but please test.
> If works for you, please either create a Github PR or a review on the
> FreeBSD' phab.
I find a Pull Request for OpenZFS on github tends to get mav@'s
attention pretty quickly, so I think that is the better way to go.

rick

>