Hi Chad,
Chad Mynhier wrote:
> Would someone be wiling to verify that I'm doing the right thing in
> the following?
>
> I have a kernel crash dump from an x64 server with the following backtrace:
>
>> $C
> fffffe800017fc30 strcmp()
> fffffe800017fc90 vfs_setmntopt_nolock+0x147()
> fffffe800017fce0 vfs_parsemntopts+0x96()
> fffffe800017fe10 domount+0xc87()
> fffffe800017fe90 mount+0x105()
> fffffe800017fed0 syscall_ap+0x97()
> fffffe800017ff20 sys_syscall32+0xef()
> 00000000080b2b80 0xfe45a0cc()
>>
>
> What I'd like to do is print the contents of the vnode_t that is the
> third argument to domount(). domount() moves %rdx to %r15 (with no
> intervening overwrite), and vfs_parsemntopts() pushes %r15 onto the
> stack:
>
>> vfs_parsemntopts::dis
> vfs_parsemntopts: pushq %rbp
> vfs_parsemntopts+1: movq %rsp,%rbp
> vfs_parsemntopts+4: pushq %r15
> [ ... ]
Were you aware of the ::findstack dcmd, particularly with the -v option?
By way of example:
::threadlist -v
ADDR PROC LWP CLS PRI WCHAN
....
ffffffff9bd718e0 ffffffffae30b3d0 ffffffff9cfde0e0 1 59 ffffffff860e3eb6
PC: _resume_from_idle+0xf8 CMD: /usr/sbin/syslogd
stack pointer for thread ffffffff9bd718e0: fffffe8000ec1ce0
[ fffffe8000ec1ce0 _resume_from_idle+0xf8() ]
swtch+0x241()
cv_wait+0x83()
zil_commit+0x2bf()
zfs_fsync+0xa1()
fop_fsync+0x31()
fdsync+0x3b()
sys_syscall32+0x1ff()
> ffffffff9bd718e0::findstack -v
stack pointer for thread ffffffff9bd718e0: fffffe8000ec1ce0
[ fffffe8000ec1ce0 _resume_from_idle+0xf8() ]
fffffe8000ec1d20 swtch+0x241()
fffffe8000ec1d50 cv_wait+0x83(ffffffff860e3eb6, ffffffff860e3e40)
fffffe8000ec1dd0 zil_commit+0x2bf(ffffffff860e3e40, 63bbb, 10)
fffffe8000ec1e30 zfs_fsync+0xa1(ffffffff946f05c0, 10, ffffffff856c2720)
fffffe8000ec1e80 fop_fsync+0x31(ffffffff946f05c0, 10, ffffffff856c2720)
fffffe8000ec1eb0 fdsync+0x3b(5, 10)
fffffe8000ec1f00 sys_syscall32+0x1ff()
> I grab the value off the stack and print it as a vnode_t:
>
>> fffffe800017fce0-8/J
> 0xfffffe800017fcd8: ffffffff827afdc0
>> ffffffff827afdc0::print -t vnode_t
> [ ... ]
> char *v_path = 0xffffffff97b11e70 "/netapp/some/filesystem"
> [ ... ]
For the panic thread, you can type
::regs
and get the register contents.
> (Filesystem name changed to protect the innocent.)
> Given that I find something that looks like a vnode_t at that
> location, I'm inclined to think this is right, but given that I'm
> fumbling my way through this with the help of Frank Hoffman's book,
> I'm not willing to rule out the possibility that I've randomly hit a
> different vnode_t.
My simple rule of thumb in cases like this is to print the entire
structure and look at each field to see whether it seems sane. Not
very hi-tech, sure, but you rapidly get to figure out whether you're
on the right track. That said, if the vnode's v_path and vnodeops
elements match up with arg0 (char *fsname) then you should have a
reasonable degree of confidence that you're looking at the right
in-kernel object.
best regards,
James C. McPherson
