mount_smbfs lock order traversal kernel segfault

From: <sahil.cooner_at_gmail.com>
Date: Mon, 23 Nov 2009 02:54:43 -0600
Fellow FreeBSDers,

I'd like to report a new lock order traversal bug that I have come across in
freebsd-current, from a checkout of the /usr/src tree a couple days ago.

I found the following site and search for the particular LOR dump that I was
receiving in dmesg.  I am currently receiving 2 different LOR errors.  One
that is a known and reported issue, the other I could not find on the
following list, http://sources.zabbadoz.net/freebsd/lor.html.

Following these instructions ...
http://sources.zabbadoz.net/freebsd/lor.html#howtoreportalor

1) The Backtrace...
smb_co_lock: recursive lock for object 1
lock order reversal:
 1st 0xffffff0020401c08 smb_vc (smb_vc) _at_
/usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:331
 2nd 0xffffffff812c84a8 smbsm (smbsm) _at_
/usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:354
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
__lockmgr_args() at __lockmgr_args+0xcf3
smb_co_lock() at smb_co_lock+0x61
smb_co_gone() at smb_co_gone+0x34
smb_sm_lookup() at smb_sm_lookup+0x105
smb_usr_lookup() at smb_usr_lookup+0xcd
nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1e7
giant_ioctl() at giant_ioctl+0x75
devfs_ioctl_f() at devfs_ioctl_f+0x76
kern_ioctl() at kern_ioctl+0xc5
ioctl() at ioctl+0xfd
syscall() at syscall+0x1ae
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80094b92c, rsp =
0x7fffffffe128, rbp = 0x7fffffffe540 ---

2) The Samba server is a Debian box running Samba versions as follows...
smbd -V
Version 3.2.5
nmbd -V
Version 3.2.5

3) uname -arv
FreeBSD mybox.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Nov 21 07:47:20
CST 2009     root_at_mybox.com:/usr/obj/usr/src/sys/GENERIC  amd64


This bug is almost always reproducible when any sort of slightly higher than
normal disk I/O takes place to the samba mounted directory, ie. a copy from
the remote target to the local drive of a 1GB file.

I haven't really had a chance to follow up by looking through the relevant
/usr/src/sys/../../smbfs/../*.c files to try and debug/determine some more
information I will respond with relevant follow ups.

Cheers,
Sahil R Cooner

Pablo Picasso<http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html>
- "Computers are useless. They can only give you answers."
Received on Mon Nov 23 2009 - 08:17:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC