From nobody Tue Apr 14 09:52:53 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fw02W0msCz6ZXPj for ; Tue, 14 Apr 2026 09:53:07 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4fw02V39sfz3MKM for ; Tue, 14 Apr 2026 09:53:06 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 63E9qssM042532; Tue, 14 Apr 2026 12:52:57 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 63E9qssM042532 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 63E9qrX5042531; Tue, 14 Apr 2026 12:52:54 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 14 Apr 2026 12:52:53 +0300 From: Konstantin Belousov To: Jan Martin Mikkelsen Cc: current@freebsd.org Subject: Re: Panic: cache_vop_rename: lingering negative entry Message-ID: References: <2016260A-5C07-45EE-87CA-73918BA16E83@transactionware.com> <44E3FE9A-4244-49EB-97E0-16080B68F12B@transactionware.com> <0610AE32-DD37-401B-BA04-8C092D61C8B3@transactionware.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0610AE32-DD37-401B-BA04-8C092D61C8B3@transactionware.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4fw02V39sfz3MKM X-Spamd-Bar: ---- 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 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.