Date: Wed, 27 Dec 2006 11:20:17 GMT From: "Ulrich Spoerlein" <uspoerlein@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze Message-ID: <200612271120.kBRBKH9P026610@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/92785; it has been noted by GNATS.
From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: "Konstantin Belousov" <kostikbel@gmail.com>
Cc: bug-followup@freebsd.org, "Bruce Evans" <bde@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612271120.kBRBKH9P026610>