Date: Sun, 2 Nov 2008 16:37:24 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Yuri Pankov" <yuri.pankov@gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs Message-ID: <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> In-Reply-To: <20081102123100.GA1434@darklight.homeunix.org> References: <20081102123100.GA1434@darklight.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/11/2, Yuri Pankov <yuri.pankov@gmail.com>:
> Hi,
>
> Trying to mount nonexistent smb share with mount_smbfs leads to
> following panic:
>
> # mount_smbfs //yuri@lifebane/blahblah /mnt
>
> Unread portion of the kernel message buffer:
> smb_co_lock: recursive lock for object 1
> panic: Lock (lockmgr) smb_vc not locked @
> /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329.
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> panic() at panic+0x182
> witness_assert() at witness_assert+0x21a
> __lockmgr_args() at __lockmgr_args+0x17a
> smb_co_put() at smb_co_put+0x76
> smb_sm_lookup() at smb_sm_lookup+0xfe
> smb_usr_lookup() at smb_usr_lookup+0xcd
> nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6
> giant_ioctl() at giant_ioctl+0x75
> devfs_ioctl_f() at devfs_ioctl_f+0x76
> kern_ioctl() at kern_ioctl+0x92
> ioctl() at ioctl+0xfd
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp =
> 0x7fffffffe038, rbp = 0x7fffffffe450 ---
> Uptime: 6m46s
> Physical memory: 2032 MB
So, what is happening here is that smb_co_lock() is AFU.
Infact looking at the code:
int
smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td)
{
...
if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE &&
(flags & LK_CANRECURSE) == 0) {
SMBERROR("recursive lock for object %d\n", cp->co_level);
return 0;
}
...
from that it is obvious that smb_co_lock() won't recurse the lock
really, but will let believe the consumer it acquired the lock
successfully without panicking at all (the printf is like a little
joke there).
I think that we don't panic here mainly because these are "user
driver" events and we want avoid to get a DoS for the kernel but it is
an unacceptable code also.
This can be fixed by allowing recuring lockmgr by default but the
problem is more vaste.
For example, it would be very nice to drop the LK_DRAIN support from
netsmb in order to completely remove it from the 8.0 kernel serie and
kill a bogus / dangerous option for lockmgr. It would be a cornerstone
for lockmgr wealth really.
What really is missing here is a valid netsmb maintainer, someone that
knows well the layers involved, is motivated to work on it and can
take advantage from the other kernel developer experience on the most
hardcore parts.
It would be also nice, for example, to bring in some Apple's changes
(like the crypto support).
Someone willing to step in would be very appreciated.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10811020737g211dfb3fs54b48e4071db2393>