Re:_VNASSERT_failed:_vp-›v_holdent_ ›_0_not_true_at_/home/pkgbuild/worktrees/main/sys/kern/ vfs_subr.c:3391_(vget_finish_ref)_[3rd_example ,_namei()..vget_finish_ref()_is_common]

On Apr 9, 2025, at 05:05, Mark Millard <marklmi@yahoo.com> wrote:

> On Apr 6, 2025, at 19:29, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> [Somewhat hand corrected "OCR" conversion of some console image content.]
>> 
>> VNASSERT failed: vp->v_holdcnt > 0 not true at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
>> 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op 0xffff0001a2cb40f0
>>   usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
>>   hold count flags ()
>>   flags ()
>>   lock type ufs: SHARED (count 1)
>>       vp=0xffffa006e11e6a50, lowervp=0xffffa004b074adc0
>> panic: condition vp->v_holdcnt > 0 not met at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
>> cpuid = 8
>> time = 1743988125
>> 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
>> vget_finish_ref() at vget_finish_ref+0x1a4
>> null_hashget() at null_hashget+0xe4
>> null_nodeget() at null_nodeget+0x34
>> null_lookup() at null_lookup+0x118
>> vfs_lookup() at vfs_lookup+0x3e0
>> namei() at namei+0x298
>> vn_open_cred() at vn_open_cred+0x450
>> openatfp() at openatfp+0x238
>> do_el0_sync() at do_el0_sync+0x608
>> handle_el0_sync() at handle_el0_sync+0x4c
>> --- exception, esr 0x56000000
>> KDB: enter: panic
>> [ thread pid 8113 tid 163110 ]
>> stopped at
>> kdb_enter+0x48: str xzr, [x19, #2048]
>> db> 
>> 
>> An issue may be that I'd not yet updated the world yet after
>> updating and booting the kernel (but no ipfw usage involved):
>> 
>> # uname -apKU
>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034
>> 
>> (That kernel is from installing an official PkgBase set of
>> kernels, not a personal build.)
>> 
>> # poudriere jail -l
>> JAILNAME         VERSION         OSVERSION ARCH          METHOD  TIMESTAMP           PATH
>> release-aarch64  14.2-RELEASE-p1           aarch64       pkgbase 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64
>> . . .
>> 
>> The FreeBSD context is Apple Silicon M4 MAX under Parallels
>> on macOS. FreeBSD had been doing a poudriere-devel based bulk
>> build.
>> 
>> 
>> I've no known way to reproduce the panic on demand.
>> 
>> 
>> Core dumps under Parallels always seem to have backtraces
>> that are like:
>> 
>> #0  0xffff0000004b9e48 in doadump (textdump=0)
>>   at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404
>> #1  0x6fa60000000e9d98 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> 
>> and the rest of the cores are like:
>> 
>> #0  0xffff0000008703b0 in ipi_stop (dummy=<optimized out>)
>>   at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342
>> #1  0xd2e9000000866b68 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Again during a poudriere bulk run:
> 
> VNASSERT failed: vp->v_holdcnt > 0 not true at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
> 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op 0xffff0001a2cd80f0
>    usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0
>    hold count flags ()
>    flags ()
>    v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0
>    lock type ufs: SHARED (count 2)
>        vp=0xffffa001e559fa50, lowervp=0xffffa0031f0b2a50
> panic: condition vp->v_holdcnt > 0 not met at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
> cpuid = 2
> time = 1744180482
> 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
> vget_finish_ref() at vget_finish_ref+0x1a4
> null_hashget() at null_hashget+0xe4
> null_nodeget() at null_nodeget+0x34
> null_lookup() at null_lookup+0x118
> vfs_lookup() at vfs_lookup+0x3e0
> namei() at namei+0x298
> sys___realpathat() at sys___realpathat+0xb0
> do_el0_sync() at do_el0_sync+0x608
> handle_el0_sync() at handle_el0_sync+0x4c
> --- exception, esr 0x56000000
> KDB: enter: panic
> 
> Here:
> namei() at namei+0x298
> sys___realpathat() at sys___realpathat+0xb0
> do_el0_sync() at do_el0_sync+0x608
> 
> Previously: 
> namei() at namei+0x298
> vn_open_cred() at vn_open_cred+0x450
> openatfp() at openatfp+0x238
> do_el0_sync() at do_el0_sync+0x608
> 
> So it looks like what is common is: namei()..vget_finish_ref()
> 
> vget_finish_ref() at vget_finish_ref+0x1a4
> null_hashget() at null_hashget+0xe4
> null_nodeget() at null_nodeget+0x34
> null_lookup() at null_lookup+0x118
> vfs_lookup() at vfs_lookup+0x3e0
> namei() at namei+0x298
> 
> This one had a v_object output line, the prior one did not.
> Some counts vary.

VNASSERT failed: vp->v_holdcnt > 0 not true at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
0xffffa00a2a17ec08: type VDIR state VSTATE_CONSTRUCTED op 0xffff0001a2cb40f0
    usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
    hold count flags ()
    flags ()
    v_object 0xffffa00a40b73000 ref 0 pages 0 cleanbuf 0 dirtybuf 0
    lock type ufs: SHARED (count 2)
        vp=0xffffa00a2a17ec08, lowervp=0xffffa00a2a21f6e0
panic: condition vp->v_holdcnt > 0 not met at /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
cpuid = 7
time = 1744203937
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
vget_finish_ref() at vget_finish_ref+0x1a4
null_hashget() at null_hashget+0xe4
null_nodeget() at null_nodeget+0x34
null_lookup() at null_lookup+0x118
vfs_lookup() at vfs_lookup+0x3e0
namei() at namei+0x298
kern_statat() at kern_statat+0xf4
sys_fstatat() at sys_fstatat+0x2c
do_el0_sync() at do_el0_sync+0x608
handle_el0_sync() at handle_el0_sync+0x4c
--- exception, esr 0x56000000
KDB: enter: panic

Here:
namei() at namei+0x298
kern_statat() at kern_statat+0xf4
sys_fstatat() at sys_fstatat+0x2c
do_el0_sync() at do_el0_sync+0x608

The *statat() are distinct from the prior examples.

Again the common part is:

vget_finish_ref() at vget_finish_ref+0x1a4
null_hashget() at null_hashget+0xe4
null_nodeget() at null_nodeget+0x34
null_lookup() at null_lookup+0x118
vfs_lookup() at vfs_lookup+0x3e0
namei() at namei+0x298

===
Mark Millard
marklmi at yahoo.com