kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze

Ulrich Spoerlein uspoerlein at gmail.com
Wed Dec 27 03:20:18 PST 2006


The following reply was made to PR kern/92785; it has been noted by GNATS.

From: "Ulrich Spoerlein" <uspoerlein at gmail.com>
To: "Konstantin Belousov" <kostikbel at gmail.com>
Cc: bug-followup at freebsd.org, "Bruce Evans" <bde at zeta.org.au>
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 <uspoerlein at gmail.com> 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


More information about the freebsd-bugs mailing list