Re: SMP FFS Part 3

On Sat, 4 Dec 2004, Robert Watson wrote:

> The first update of the same tree didn't cause a problem, so maybe it's
> a path we hit the second time due to cached lookups/etc? 

A little bit more information from gdb:

(kgdb) bt   
#0  doadump () at pcpu.h:159
#1  0xc0460cba in db_fncall (dummy1=-1067294688, dummy2=0, dummy3=-1, 
    dummy4=0xef1ff9cc "") at ../../../ddb/db_command.c:531
#2  0xc0461050 in db_command_loop () at ../../../ddb/db_command.c:349
#3  0xc0462a7c in db_trap (type=3, code=0) at ../../../ddb/db_main.c:221
#4  0xc06263e6 in kdb_trap (type=3, code=0, tf=0xef1ffaf4)
    at ../../../kern/subr_kdb.c:421
#5  0xc07b420c in trap (frame=
      {tf_fs = -283181032, tf_es = -1067319280, tf_ds = -1065287664,
tf_edi = 0, tf_esi = 1, tf_ebp = -283116748, tf_isp = -283116768, tf_ebx =
-283116704, tf_edx = -1065230914, tf_ecx = -1064437184, tf_eax =
-1065222375, tf_trapno = 3, tf_err = 0, tf_eip = -1067294688, tf_cs = 8,
tf_eflags = 642, tf_esp = -283116716, tf_ss = -1067387953}) at
../../../i386/i386/trap.c:573
#6  0xc07a2d6a in calltrap () at ../../../i386/i386/exception.s:140
#7  0xef1f0018 in ?? ()
#8  0xc0620010 in blst_leaf_alloc (scan=0x0, blk=1102741364158, count=0)
    at ../../../kern/subr_blist.c:394
#9  0xc060f3cf in panic (fmt=0x282 <Address 0x282 out of bounds>)
    at ../../../kern/kern_shutdown.c:538
#10 0xc062f1b8 in witness_unlock (lock=0xc08de5a0, flags=8, 
    file=0xc0825f81 "kern/vfs_lookup.c", line=220)
    at ../../../kern/subr_witness.c:1105
#11 0xc0607f83 in _mtx_unlock_flags (m=0xc08de5a0, opts=0, 
    file=0xc0825f78 "../../../kern/vfs_lookup.c", line=220)
    at ../../../kern/kern_mutex.c:296
#12 0xc065c26c in namei (ndp=0x1) at ../../../kern/vfs_lookup.c:220
#13 0xc06686fe in stat (td=0xc2b23c00, uap=0xef1ffd14)
    at ../../../kern/vfs_syscalls.c:2091
#14 0xc07b4650 in syscall (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135020764, tf_esi =
135009282, tf_ebp = -1077941384, tf_isp = -283116172, tf_ebx = 674566284,
tf_edx = 33619715, tf_ecx = 135012361, tf_eax = 188, tf_trapno = 12,
tf_err = 2, tf_eip = 674072391, tf_cs = 31, tf_eflags = 530, tf_esp =
-1077942068, tf_ss = 47})
    at ../../../i386/i386/trap.c:951
#15 0xc07a2dbf in Xint0x80_syscall () at
../../../i386/i386/exception.s:201
#16 0x0000002f in ?? ()
<garbage>
#44 0xc061f6ff in sched_switch (td=0x80c1402, newtd=0x2835108c,
flags=Cannot access memory at address 0xbfbfeb88
)
    at ../../../kern/sched_4bsd.c:865

In the stat() frame:

(kgdb) inspect nd
$3 = {ni_dirp = 0x80c2000 <Address 0x80c2000 out of bounds>, 
  ni_segflg = 16777216, ni_startdir = 0x0, ni_rootdir = 0xc2731bdc, 
  ni_topdir = 0x0, ni_vp = 0xc2731bdc, ni_dvp = 0xc277a8a0, ni_pathlen =
1, 
  ni_next = 0xc280000b "", ni_loopcnt = 0, ni_cnd = {cn_nameiop = 0, 
    cn_flags = 2154692, cn_thread = 0xc2b23c00, cn_cred = 0xc2934280, 
    cn_pnbuf = 0xc2800000 "../../../..", cn_nameptr = 0xc2800009 "..", 
    cn_namelen = 2, cn_consume = 0}}

Looks like cvs was looking up all theway to the root, from an NFS subdir
to a UFS root.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research