[Bug 234296] FreeBSD 12.0-STABLE r342216 Fatal trap 12

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234296

--- Comment #7 from Mark Johnston <markj at FreeBSD.org> ---
I looked at the kernel dumps.  In all three cases, we crashed while processing
a callout that had been mostly zeroed out.  However, in all cases, at offset
0x10 into the callout there is a pointer in the direct map.  Following that
pointer leads me to the middle of a ZFS vnode:

(kgdb) frame 9
#9  0xffffffff805dd328 in callout_process (now=91167878320709) at
/usr/src/sys/kern/kern_timeout.c:510
510                                             LIST_REMOVE(tmp, c_links.le);
(kgdb) p/x *cc->cc_callwheel[firstb & callwheelmask].lh_first
$21 = {
  c_links = {
    le = {
      le_next = 0x0, 
      le_prev = 0x0
    }, 
    sle = {
      sle_next = 0x0
    }, 
    tqe = {
      tqe_next = 0x0, 
      tqe_prev = 0x0
    }
  }, 
  c_time = 0xfffff803773850c0, 
  c_precision = 0x0, 
  c_arg = 0x0, 
  c_func = 0x0, 
  c_lock = 0x0, 
  c_flags = 0x0, 
  c_iflags = 0x0, 
  c_cpu = 0x0
}
(kgdb) x/32g 0xfffff803773850c0
0xfffff803773850c0:     0x0000000000000000      0xfffff8000a161de0
0xfffff803773850d0:     0xffffffff809bf965      0x0000000005230000
0xfffff803773850e0:     0x0000000000000000      0x0000000000000001
0xfffff803773850f0:     0xffffffff80c96170      0xfffff80463b90100
0xfffff80377385100:     0x0000000000000000      0x0000000000000000
0xfffff80377385110:     0xfffff80377385000      0x0000000000000000
0xfffff80377385120:     0xfffff80377385118      0x0000000000000000
0xfffff80377385130:     0x0000000000000000      0x0000000000000000
0xfffff80377385140:     0xfffff80377385138      0x0000000000000000
0xfffff80377385150:     0x0000000000000000      0x0000000000000000
0xfffff80377385160:     0x0000000300000000      0x0000000000020000
0xfffff80377385170:     0x0000000000000000      0x0000000000000000
0xfffff80377385180:     0x0000000000000000      0x0000000000000000
0xfffff80377385190:     0xfffff80377385188      0x0000000000000000
0xfffff803773851a0:     0x0000000000000000      0x0000000000000000
0xfffff803773851b0:     0x0000000000000000      0x0000000200000000

0xffffffff809bf965 is a pointer to the string "bufobj interlock".
So the pointer in this callout is to the v_actfreelist member
of a vnode.  Indeed, 0xfffff803773850c0 & ~0xff is a pointer to
a ZFS vnode.  So, the pointer in the callout structure is probably
the prev pointer, which means the callout structure is actually
embedded in a vnode.

(kgdb) p *(struct vnode * )((uintptr_t)$23 & ~0xff)
$24 = { 
  v_tag = 0x0,   
  v_op = 0x0,      
  v_data = 0x0,
  v_mount = 0xfffff8000a3fb000,
  v_nmntvnodes = {
    tqe_next = 0x0,  
    tqe_prev = 0x0
  },              
...
  v_vnlock = 0x0,
  v_actfreelist = {
    tqe_next = 0x0,
    tqe_prev = 0xfffff803773850c0
  },
...
  v_iflag = 0,
  v_vflag = 0,
  v_mflag = 0,
  v_writecount = 0,
  v_hash = 0,
  v_type = VMARKER
}

So the only non-zero fields are those of a marker
vnode initialized in __mnt_vnode_first_active().  Those
vnodes are allocated using malloc(), not the vnode zone.

-- 
You are receiving this mail because:
You are the assignee for the bug.