From owner-freebsd-current@FreeBSD.ORG Sun Nov 2 16:05:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6117A106564A for ; Sun, 2 Nov 2008 16:05:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 329AD8FC19 for ; Sun, 2 Nov 2008 16:03:47 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so2131818mue.3 for ; Sun, 02 Nov 2008 08:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LT5dNGkZQ+4MP582TSUWXiFjMZWtCaSCeuIj4a+Irc0=; b=ohTTz9L40DoVQ4rLLZy/09zUEd2h2NZIwtX5FikT683JJlWd9H6gaDFetP7KQbESyS v/o8a5+Qa9gRNcZof4uWymkGQGqKyB5Yw4KTsXdvWBlOaHaRpPA/25Qt4ZiOEt4EAW5F IlE1tUwHWXrAWQfs/Y3pzk3n54OGWlYVDS6rQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=DRoLWXO+jS1g7d3bEPD2Oz/VySMnckfJJs7xdjlDoW/46vXi24jcESYDFIS5ww3uAX HBXtClziY6vDO+ECM7TkGFcvV+eAde2FN7Eu8Ka6ctG3DhEQheylX5Ddh5PPt64Cll5u rZ50xoGX9UYo3cOET8gaGa60kA8ObE0zdTJ6I= Received: by 10.103.22.16 with SMTP id z16mr4275515mui.78.1225640244103; Sun, 02 Nov 2008 07:37:24 -0800 (PST) Received: by 10.103.239.14 with HTTP; Sun, 2 Nov 2008 07:37:24 -0800 (PST) Message-ID: <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> Date: Sun, 2 Nov 2008 16:37:24 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yuri Pankov" In-Reply-To: <20081102123100.GA1434@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> X-Google-Sender-Auth: 47038d8779c02b0d Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2008 16:05:10 -0000 2008/11/2, Yuri Pankov : > 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