e originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4fw3tC6Tj9z3pCF X-Spamd-Bar: ---- On Tue, Apr 14, 2026 at 2:53=E2=80=AFAM Konstantin Belousov wrote: > > On Tue, Apr 14, 2026 at 11:45:08AM +0200, Jan Martin Mikkelsen wrote: > > > > > On 13 Apr 2026, at 22:13, Konstantin Belousov 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 wrote: > > >>> > > >>> On 7 Apr 2026, at 18:53, Konstantin Belousov wrot= e: > > >>>> > > >>>> On Tue, Apr 07, 2026 at 05:02:05PM +0200, Jan Martin Mikkelsen wro= te: > > >>>>> Hi, > > >>>>> > > >>>>> I am consistently getting the panic below while building lang/per= l5.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 lat= er 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 =3D 4 > > >>>>> time =3D 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=E2=80=99t try multiple tim= es, but it never works on ZFS. > > >> > > >> The panic consistently reproduces on a ZFS filesystem with the prope= rties =E2=80=9Cutf8only=3Don=E2=80=9D and "normalization=3DformD=E2=80=9D. > > >> > > >> A ZFS file system with =E2=80=9Cutf8only=3Doff=E2=80=9D and "normali= zation=3Dnone=E2=80=9D works fine. > > >> > > >> As far as I can see, strip makes a simple rename(2) call, and testin= g 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 tha= t > > > zfs had option to be case-insensitive, but I may mis-remember. > > > > > > The solution, in any case, is to either stop using namecache when the= se > > > 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 =3D !zfsvfs->z_norm || > > ((zfsvfs->z_case =3D=3D ZFS_CASE_MIXED) && > > !(zfsvfs->z_norm & ~U8_TEXTPREP_TOUPPER)); > > > > > > The call to cache_vop_rename() which causes the panic is not protected = by an =E2=80=9Cif (zfsvfs->z_use_namecache)=E2=80=9D, unlike the rest of th= e 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* func= tion, 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 see= m reasonable? > > > > --- a/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c 2= 026-03-28 20:55:06.000000000 1100 > > +++ b/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c 2= 026-03-28 20:55:06.000000000 1100 > > @@ -3524,7 +3524,7 @@ > > ZRENAMING, NULL)); > > } > > } > > - if (error =3D=3D 0) { > > + if (error =3D=3D 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 >