fffe008dfd0f30
> >     fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe008dfd0f30
> >     --- trap 0xc, rip =3D 0x2a07bda3b4ea, rsp =3D 0x2a07bc818ed8, rbp =
=3D 0x2a07bc819170 ---
> >     vnode 0xfffff8007dfdac08: type VDIR state VSTATE_CONSTRUCTED op 0xf=
fffffff822fc120
> >         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 shoul=
d 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 po=
int
> and it doesn't relock vp. I haven't touched this code in decades, so I ne=
ed 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() w=
hile
the vnode is still locked.

rick

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