So I'm trying to analyze my panic:

> uvm_fault(0xffff8497fe928050, 0x0, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip 0xffffffff80a165f3 cs 0x8 rflags 0x10282 cr2 0x80 
> ilevel 0 rsp 0xffffa384c28b4cd0
> curlwp 0xffff84980a57f240 pid 11740.11740 lowest kstack 0xffffa384c28b02c0
> kernel: page fault trap, code=0
> Stopped in pid 11740.11740 (python3.10) at    netbsd: VOP_LOCK+0x26: movl     
> 80(%rdi),%r13d
> db{3}> bt
> VOP LOCK() at netbsd:VOP_LOCK+0x26
> vn_lock() at netbsd:vn_lock+0x22
> ufs_link() at netbsd:ufs_link+0x3c
> VOP_LINK() at netbsd:VOP_LINK+0x46
> union_link() at netbsd:union_link+0x53
[...]
> db{3}> show reg
[...]
> rdi   0
[...]

So the panic is VOP_LOCK() called with a null argument, meaning vn_lock() 
called with a null argument, meaning ufs_link() called with a null a->a_vp,
meaning VOP_LINK() called with a null vp, meaning union_link() calling it 
with a null vp.

union_link() looks like this:

int
union_link(void *v)
{
        struct vop_link_v2_args /* {
                struct vnode *a_dvp;
                struct vnode *a_vp;
                struct componentname *a_cnp;
        } */ *ap = v;
[...]
        struct vnode *vp;
[...]
        if (ap->a_dvp->v_op != ap->a_vp->v_op) {
                vp = ap->a_vp;
        } else {
                struct union_node *un = VTOUNION(ap->a_vp);
                if (un->un_uppervp == NULLVP) {
                        [MAGIC CODE]
                }
                vp = un->un_uppervp;
        }
[...]
        return VOP_LINK(dvp, vp, cnp);
}

and I'm at loss how [MAGIC CODE], which dosn't seem to touch un or 
un->unuppervp, can turn a NULLVP un->un_uppervp into a non-NULLVP one.

Reply via email to