From owner-freebsd-bugs@FreeBSD.ORG Wed Dec 27 11:20:18 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13AA516A412 for ; Wed, 27 Dec 2006 11:20:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E3D3313C47E for ; Wed, 27 Dec 2006 11:20:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kBRBKHu5026612 for ; Wed, 27 Dec 2006 11:20:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kBRBKH9P026610; Wed, 27 Dec 2006 11:20:17 GMT (envelope-from gnats) Date: Wed, 27 Dec 2006 11:20:17 GMT Message-Id: <200612271120.kBRBKH9P026610@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Ulrich Spoerlein" Cc: Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ulrich Spoerlein List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2006 11:20:18 -0000 The following reply was made to PR kern/92785; it has been noted by GNATS. From: "Ulrich Spoerlein" To: "Konstantin Belousov" Cc: bug-followup@freebsd.org, "Bruce Evans" Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze Date: Wed, 27 Dec 2006 11:43:36 +0100 On 12/18/06, Ulrich Spoerlein wrote: > Konstantin Belousov wrote: > > Try this (not ever booted kernel with this patch applied, beware). > > > > Index: ufs/ufs/ufs_lookup.c > > [...] > PS: Since this fix is UFS specific, what's with the other filesystems > that can be NFS exported? I think I'll do some test with ext2fs or > msdosfs exported filesystems next week. While the patch for UFS seems to quiesce the lock-leak in nfsd I now exported a FAT32 filesystem. All Linux clients can access the export just fine, mounting it from OS/2 will result in the following panic, after issuing a 'dir' in the mounted drive. The dir-command will print the first line (the "."-DIR) and when trying to look up ".." the nfs server paniced. panic: lockmgr: locking against myself cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c8921480,3002,80,c8921480,...) at kdb_backtrace+0x29 panic(c0892ac6,c8921480,0,f,c066875d,...) at panic+0x114 lockmgr(cabf8724,3002,cabf8794,c8921480,eaf8175c,...) at lockmgr+0x3fe vop_stdlock(eaf8177c) at vop_stdlock+0x21 VOP_LOCK_APV(c0902ce0,eaf8177c) at VOP_LOCK_APV+0x87 vn_lock(cabf86cc,1002,c8921480,c86cc800,0,1fffffff,eaf81800) at vn_lock+0xac msdosfs_lookup(eaf81880) at msdosfs_lookup+0x6a5 VOP_CACHEDLOOKUP_APV(c0902ce0,eaf81880) at VOP_CACHEDLOOKUP_APV+0x9b vfs_cache_lookup(eaf8191c) at vfs_cache_lookup+0xb5 VOP_LOOKUP_APV(c0902ce0,eaf8191c) at VOP_LOOKUP_APV+0x87 lookup(eaf81c0c) at lookup+0x46e nfs_namei(eaf81c0c,eaf81b3c,2,c8f11700,c88834b0,eaf81a24,eaf81a28,eaf81a10,0,eaf81a5c,eaf81a14,c8921480,0,eaf81b3c) at nfs_namei+0x40e nfsrv_lookup(ca3cfd00,c8f11700,c8921480,eaf81c98) at nfsrv_lookup+0x1dd nfssvc_nfsd(c8921480) at nfssvc_nfsd+0x3d9 nfssvc(c8921480,eaf81d04) at nfssvc+0x18c syscall(3b,3b,3b,1,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- KDB: enter: panic [thread pid 6102 tid 100104 ] Stopped at kdb_enter+0x2b: nop db> show alllocks Process 6102 (nfsd) thread 0xc8921480 (100104) exclusive sleep mutex Giant r = 0 (0xc0973480) locked @ /usr/src/sys/nfsserver/nfs_srvsubs.c:675 db> show lockedvnods Locked vnodes 0xcabf86cc: tag msdosfs, type VDIR usecount 4, writecount 0, refcount 5 mountedhere 0 flags (VV_ROOT) v_object 0xcd2d0000 ref 0 pages 0 lock type msdosfs: EXCL (count 1) by thread 0xc8921480 (pid 6102)#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc06c1665 at vop_stdlock+0x21 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06ca4ca at vget+0xc2 #5 0xc06c24a9 at vfs_hash_get+0x8d #6 0xc061f4e4 at deget+0x64 #7 0xc0621da4 at msdosfs_lookup+0x690 #8 0xc083641b at VOP_CACHEDLOOKUP_APV+0x9b #9 0xc06bf499 at vfs_cache_lookup+0xb5 #10 0xc0836347 at VOP_LOOKUP_APV+0x87 #11 0xc06c3626 at lookup+0x46e #12 0xc0734fba at nfs_namei+0x40e #13 0xc0726d81 at nfsrv_lookup+0x1dd #14 0xc0736765 at nfssvc_nfsd+0x3d9 #15 0xc07360b4 at nfssvc+0x18c #16 0xc0825a07 at syscall+0x25b #17 0xc0811f7f at Xint0x80_syscall+0x1f startcluster 2, dircluster 2, diroffset 536870911, db> (Please note, the ddb prompt seems to be cut off here) I will now try the same test with revison 1.103 of vfs_cache.c backed out as suggested by Bruce. Uli