Re: NFS panic in latest main

On Thu, Jul 17, 2025 at 3:53 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Thu, Jul 17, 2025 at 6:42 AM Dag-Erling Smørgrav <des@freebsd.org> wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca.
> >
> > I have another one:
> >
> >     db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008dfd0490
> >     assert_vop_locked() at assert_vop_locked+0x49/frame 0xfffffe008dfd04b0
> >     VOP_PATHCONF_APV() at VOP_PATHCONF_APV+0x42/frame 0xfffffe008dfd04e0
> >     nfsv4_fillattr() at nfsv4_fillattr+0xfa8/frame 0xfffffe008dfd0670
> >     nfsvno_fillattr() at nfsvno_fillattr+0xdd/frame 0xfffffe008dfd0710
> >     nfsrvd_getattr() at nfsrvd_getattr+0x3c6/frame 0xfffffe008dfd09a0
> >     nfsrvd_dorpc() at nfsrvd_dorpc+0x167e/frame 0xfffffe008dfd0bb0
> >     nfssvc_program() at nfssvc_program+0x852/frame 0xfffffe008dfd0db0
> >     svc_run_internal() at svc_run_internal+0xaa8/frame 0xfffffe008dfd0ee0
> >     svc_thread_start() at svc_thread_start+0xb/frame 0xfffffe008dfd0ef0
> >     fork_exit() at fork_exit+0x82/frame 0xfffffe008dfd0f30
> >     fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe008dfd0f30
> >     --- trap 0xc, rip = 0x2a07bda3b4ea, rsp = 0x2a07bc818ed8, rbp = 0x2a07bc819170 ---
> >     vnode 0xfffff8007dfdac08: type VDIR state VSTATE_CONSTRUCTED op 0xffffffff822fc120
> >         usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0
> >         hold count flags ()
> >         flags (VV_ROOT)
> >         lock type tmpfs: UNLOCKED
> >     tag VT_TMPFS, tmpfs_node 0xfffff800ada100f0, flags 0x0, links 2
> >         mode 0755, owner 0, group 0, size 0, status 0x0
> >
> >     VOP_PATHCONF Entry (vp): 0xfffff8007dfdac08 is not locked but should be
> >
> > This can be reliably triggered by running the nfsv4 test case from
> > review D51371.  Note that you will need to apply D51372 first to allow
> > the client jail to mount NFS file systems.
> The bug is in nfsrvd_getattr() at around line# 308-343. No real client
> bumps into a
> VV_ROOT vnode like this.
>
> I'll work on a patch.
>
> The code is handling the case where the getattr crosses a server mount point
> and it doesn't relock vp. I haven't touched this code in decades, so I need to
> remember exactly what needs to be done in this case?
Actually the bug was me not remembering that for server side calls to
nfsv4_fillattr()
the vnode is unlocked.

I believe relocking the vnode can cause deadlocks for the Readdirplus case, so
the patch in D51410 does the VOP_PATHCONF() calls before nfsv4_fillattr() while
the vnode is still locked.

rick

>
> I'll post a patch for testing when I have one.
>
> rick
>
> >
> > DES
> > --
> > Dag-Erling Smørgrav - des@FreeBSD.org