From owner-freebsd-stable@FreeBSD.ORG Wed Nov 1 10:57:50 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C313116A415 for ; Wed, 1 Nov 2006 10:57:50 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50F243D45 for ; Wed, 1 Nov 2006 10:57:49 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so612749nfc for ; Wed, 01 Nov 2006 02:57:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tGjv/iw9mU6c4GQmik0/GSGWc66zBCx37irq6NfPXuX1H7nJMk9eGD/y3hi2gD7hmwHIaNcapJqKtPTnlZF1n0lqjB3NzeRsQGZ7x33Ul3NC3cR9OwZREGzxZZw6/SocvVtQbQCw8gjIg4UCyZm/4Y8xVXSR5ACoPOkXBFKda7A= Received: by 10.78.128.15 with SMTP id a15mr8656631hud; Wed, 01 Nov 2006 02:57:48 -0800 (PST) Received: by 10.78.155.3 with HTTP; Wed, 1 Nov 2006 02:57:48 -0800 (PST) Message-ID: <7ad7ddd90611010257o75546455p7da194b17037f8ed@mail.gmail.com> Date: Wed, 1 Nov 2006 11:57:48 +0100 From: "Ulrich Spoerlein" To: "Kris Kennaway" , stable@freebsd.org In-Reply-To: <20061031184150.GA27161@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_22392_15033561.1162378668074" References: <7ad7ddd90610300741k5789f64j8f410b6e866b99ee@mail.gmail.com> <20061030224935.GA95120@xor.obsecurity.org> <7ad7ddd90610302348j6b7aabc7vc0a89e1e95d8fd27@mail.gmail.com> <20061031184150.GA27161@xor.obsecurity.org> Cc: Subject: Re: panic: vfs_getopt: caller passed 'opts' as NULL X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 10:57:50 -0000 ------=_Part_22392_15033561.1162378668074 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/31/06, Kris Kennaway wrote: > Note that they'll be demand-loaded if requested (e.g. if you try to > mount_nullfs). Maybe you or something else tried to mount such a > filesystem by accident? > > > But the point is mood anyway, since I could not reproduce the problem. > > I tried again after rebooting the machine and everything went just > > fine ... > > > > I have to use the nullfs mounts on another machine shortly, let's see > > what happens there. It reliably paniced in single user mode, with no other modules loaded at the time. But, I see now that nullfs.ko is loaded as a module, which might explain everything. I assumed it was built in. I rebooted to a kernel without DEBUG_VFS_LOCKS and it's happily using nullfs. I'll try once more with a debugging kernel, that has nullfs built in, but I'll guess the panic vanishes. Ok, with the attached kernel config, which includes nullfs, I get a duplicate lock, instead of a panic Trying to mount root from ufs:/dev/da0s1a acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2036 KDB: stack backtrace: kdb_backtrace(3,c894fa80,c0a47110,c0a47110,c09cb524,...) at kdb_backtrace+0x29 witness_checkorder(c8622d04,9,c0951b38,7f4) at witness_checkorder+0x578 _mtx_lock_flags(c8622d04,0,c0951b38,7f4,c840b590,...) at _mtx_lock_flags+0x78 vrefcnt(c8622c3c) at vrefcnt+0x20 null_checkvp(c8a7ed98,c093f5ae,215) at null_checkvp+0x56 null_lock(eb0bba80) at null_lock+0x66 VOP_LOCK_APV(c09c40a0,eb0bba80) at VOP_LOCK_APV+0x87 vn_lock(c8a7ed98,1002,c894fa80,c8a7ed98,c8a89224,...) at vn_lock+0xac nullfs_root(c88052e4,2,eb0bbaf8,c894fa80,0,8,0,c0a84040,0,c09513da,3dd) at nullfs_root+0x26 vfs_domount(c894fa80,c83e64c0,c8493490,0,c83fdad0,c0a38380,0,c09513da,2a3) at vfs_domount+0x975 vfs_donmount(c894fa80,0,c87f4e00,c87f4e00,0,...) at vfs_donmount+0x2ef nmount(c894fa80,eb0bbd04) at nmount+0x8b syscall(3b,3b,3b,bfbfe435,bfbfecc8,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ba4d7, esp = 0xbfbfe3fc, ebp = 0xbfbfec78 --- I grepped /sys for DEBUG_VFS_LOCKS and it seems to only add some additional KASSERTs, but not the one which triggered in the original panic. Nullfs seems more fragile than I initially thought ... Uli ------=_Part_22392_15033561.1162378668074 Content-Type: application/octet-stream; name="DEBUG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DEBUG" X-Attachment-Id: f_etzm8kjm aW5jbHVkZQlHRU5FUklDCgppZGVudAlERUJVRwoKb3B0aW9ucyAgICAgICAgIElOQ0xVREVfQ09O RklHX0ZJTEUgICAgICMgSW5jbHVkZSB0aGlzIGZpbGUgaW4ga2VybmVsCgptYWtlb3B0aW9ucwlE RUJVRz0tZwoKb3B0aW9ucyAJS0RCICAgICAgICAgICAgICAgICAgICAgIyBFbmFibGUga2VybmVs IGRlYnVnZ2VyIHN1cHBvcnQuCm9wdGlvbnMgCUREQiAgICAgICAgICAgICAgICAgICAgICMgU3Vw cG9ydCBEREIuCm9wdGlvbnMgCUdEQiAgICAgICAgICAgICAgICAgICAgICMgU3VwcG9ydCByZW1v dGUgR0RCLgpvcHRpb25zIAlJTlZBUklBTlRTICAgICAgICAgICAgICAjIEVuYWJsZSBjYWxscyBv ZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKb3B0aW9ucyAJSU5WQVJJQU5UX1NVUFBPUlQgICAgICAg IyBFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5 IElOVkFSSUFOVFMKb3B0aW9ucyAJV0lUTkVTUyAgICAgICAgICAgICAgICAgIyBFbmFibGUgY2hl Y2tzIHRvIGRldGVjdCBkZWFkbG9ja3MgYW5kIGN5Y2xlcwpvcHRpb25zIAlXSVRORVNTX1NLSVBT UElOICAgICAgICAjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQKb3B0 aW9ucyAJRElBR05PU1RJQwoKb3B0aW9ucyAJQlJFQUtfVE9fREVCVUdHRVIKb3B0aW9ucyAJQUxU X0JSRUFLX1RPX0RFQlVHR0VSCm9wdGlvbnMgCUtEQl9UUkFDRQoKb3B0aW9ucyAJREVCVUdfTE9D S1MKb3B0aW9ucyAJREVCVUdfVkZTX0xPQ0tTCgojIEluY2x1ZGUgY3JpdGljYWwgZGV2aWNlcywg d2UgY2FuJ3QgZGVidWcgbW9kdWxlcwpkZXZpY2UJYWNwaQpkZXZpY2UJZ2VvbV9taXJyb3IKZGV2 aWNlCWdlb21fZ2F0ZQpkZXZpY2UJZ2VvbV9sYWJlbApkZXZpY2UJc21iCmRldmljZQlzbWJ1cwpk ZXZpY2UJaWNoc21iCm9wdGlvbnMJTlVMTEZTCg== ------=_Part_22392_15033561.1162378668074--