On Thu, Jul 17, 2025 at 3:53 PM Rick Macklem <[email protected]> wrote: > > On Thu, Jul 17, 2025 at 6:42 AM Dag-Erling Smørgrav <[email protected]> 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 > > [email protected]. > > > > 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 - [email protected]
