From nobody@FreeBSD.org  Sat Feb  4 02:48:40 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4004D16A420
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  4 Feb 2006 02:48:40 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 1461343D45
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  4 Feb 2006 02:48:40 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k142mdgn063422
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 4 Feb 2006 02:48:39 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k142mdwL063418;
	Sat, 4 Feb 2006 02:48:39 GMT
	(envelope-from nobody)
Message-Id: <200602040248.k142mdwL063418@www.freebsd.org>
Date: Sat, 4 Feb 2006 02:48:39 GMT
From: Luke <rockowallaby@bellsouth.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Using exported filesystem on OS/2 NFS client causes filesystem freeze
X-Send-Pr-Version: www-2.3

>Number:         92785
>Category:       kern
>Synopsis:       Using exported filesystem on OS/2 NFS client causes filesystem freeze
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kib
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 04 02:50:02 GMT 2006
>Closed-Date:    Fri Feb 23 12:28:47 GMT 2007
>Last-Modified:  Fri Feb 23 12:28:47 GMT 2007
>Originator:     Luke
>Release:        FreeBSD 6.0-RELEASE
>Organization:
>Environment:
FreeBSD 6.0-RELEASE i386
>Description:
It was discovered that using OS/2's NFS client to access an exported filesystem on a FreeBSD system causes the exported filesystem to 'freeze' whenever a file is accessed or dismounted on the OS/2 client.

This freeze causes any command (ls, etc) that tries to use the filesystem in question to hang and be unkillable (they seem to be stuck in the UFS state, according to 'ps axl' after doing a 'shutdown now'.  Trying to umount the filesystem fails, claiming it is busy.  It is impossible to properly shut down the system when this happens.

Interestingly enough, the OS/2 client can continue to access files (copy, delete, etc) on the 'frozen' filesystem, as if it had some sort of exclusive access.

This problem was not seen on an older release of FreeBSD I used (4.9) with the same NFS client.

I do not know if this problem is exclusive to the OS/2 client.

Additional info:
Running ULE scheduler with i386 SMP kernel (AMD64 chip in 32bit mode).
>How-To-Repeat:
Export a UFS2 (softupdates) filesystem for NFS on the FreeBSD system.
With the OS/2 NFS client, mount that filesystem and copy a file over to it.  Unmount the filessytem from the OS/2 client (this will probably fail).
On the FreeBSD system, attempt to access the exported filesystem (ls, etc.).  Note the 'freeze'.

Use OS/2 NFS client version:
IBM NFS for OS/2
UMOUNT Version 3.99
Release:  m17

On OS/2 Warp 4

C:\MPTN\SYSLEVEL.MPT
                    IBM OS/2 TCP/IP Stack
Version 6.01     Component ID 5639B1700
Current CSD level: WR08705
Prior   CSD level: WR08701

C:\MPTN\SYSLEVEL.NFS
                    NFS for TCP/IP on OS/2
Version 3.00.3     Component ID 5639A6602
Current CSD level: UN02205
Prior   CSD level: UN02200

>Fix:
              
>Release-Note:
>Audit-Trail:

From: Paul Argentoff <argentoff@rtelekom.ru>
To: bug-followup@freebsd.org, rockowallaby@bellsouth.net
Cc:  
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Wed, 1 Mar 2006 14:35:50 +0300

 Dear Luke,
 
 I've got the same problem with WindowsXP NFS client. Hope the developers will 
 research the problem.
 -- 
 Yours truly, WBR, Paul Argentoff.
 Jabber:	paul@jabber.rtelekom.ru
 RIPE:	PA1291-RIPE

From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: stable@freebsd.org, bug-followup@FreeBSD.org, rockowallaby@bellsouth.net, 
	"Mohan Srinivasan" <mohans@FreeBSD.org>
Cc:  
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 13:44:23 +0100

 Hi,
 
 we too, ran into this problem. OS/2 Clients kill our NFS server. It is
 running a RELENG_6 snapshot from 2006-11-14. rpc.lockd and rpc.statd
 are running. I'll conduct a test without those two services shortly.
 
 You can still log in the system with ssh and cruse around, but mountd
 is stuck in ufs state and is no longer serving requests.
 
 root@fs2:~# ps axl | grep ufs
     0 39370     1   0  -4  0  3052  2200 ufs    Ds    ??    0:00.01
 /usr/sbin/mountd -r
 
 db> show lockedvnods
 Locked vnodes
 
 0xc87b9414: tag ufs, type VDIR
     usecount 0, writecount 0, refcount 4 mountedhere 0
     flags (VV_ROOT)
     v_object 0xc8c43c60 ref 0 pages 1
      lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926)
 with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed
 #1 0xc078572e at ffs_lock+0x76
 #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 0xc07844af at ffs_vget+0x27
 #7 0xc078b253 at ufs_lookup+0xa4b
 #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
 
         ino 2, on dev da1s2e
 
 
 db> trace 6926
 Tracing pid 6926 tid 100106 td 0xc8bac300
 sched_switch(c8bac300,0,1) at sched_switch+0x177
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c8678200) at sleepq_switch+0xc1
 sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d
 msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a
 nfssvc_nfsd(c8bac300) at nfssvc_nfsd+0xe5
 nfssvc(c8bac300,eafd4d04) 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 ---
 db> trace 39370
 Tracing pid 39370 tid 100102 td 0xc8bac900
 sched_switch(c8bac900,0,1) at sched_switch+0x177
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c87b946c,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1
 sleepq_wait(c87b946c,0,c87b94dc,b7,c08929b8,...) at sleepq_wait+0x46
 msleep(c87b946c,c0972500,50,c089c1c1,0,...) at msleep+0x279
 acquire(eafe094c,40,60000,c8bac900,0,...) at acquire+0x76
 lockmgr(c87b946c,2002,c87b94dc,c8bac900) at lockmgr+0x44e
 ffs_lock(eafe09a4) at ffs_lock+0x76
 VOP_LOCK_APV(c0943320,eafe09a4) at VOP_LOCK_APV+0x87
 vn_lock(c87b9414,2002,c8bac900,c87b9414) at vn_lock+0xac
 vget(c87b9414,2002,c8bac900) at vget+0xc2
 vfs_hash_get(c86cf2e4,2,2,c8bac900,eafe0abc,0,0) at vfs_hash_get+0x8d
 ffs_vget(c86cf2e4,2,2,eafe0abc) at ffs_vget+0x27
 ufs_root(c86cf2e4,2,eafe0b00,c8bac900,0,...) at ufs_root+0x19
 lookup(eafe0ba0) at lookup+0x743
 namei(eafe0ba0) at namei+0x39a
 kern_lstat(c8bac900,bfbfd2a0,0,eafe0c74) at kern_lstat+0x47
 lstat(c8bac900,eafe0d04) at lstat+0x1b
 syscall(3b,3b,3b,281512fb,bfbfc9f1,...) at syscall+0x25b
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2813d427, esp =
 0xbfbfc5ac, ebp = 0xbfbfd268 ---
 
 I was under the impression, that you are not allowed to sleep while
 holding a lock in the FreeBSD kernel. Doesn't this also apply to the
 lockmgr itself?
 
 Upon shutting down the system, I had a panic coming in:
 
 panic: userret: Returning with 4 locks held.
 cpuid = 1
 KDB: stack backtrace:
 kdb_backtrace(100,c8bac300,c8bac3c8,c8bad218,c8bac300,...) at kdb_backtrace+0x29
 panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x114
 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183
 syscall(3b,3b,3b,1,0,...) at syscall+0x321
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp =
 0xbfbfe90c, ebp = 0xbfbfe928 ---
 KDB: enter: panic
 [thread pid 6926 tid 100106 ]
 Stopped at      kdb_enter+0x2b: nop
 db> bt
 Tracing pid 6926 tid 100106 td 0xc8bac300
 kdb_enter(c0894aec) at kdb_enter+0x2b
 panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x127
 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183
 syscall(3b,3b,3b,1,0,...) at syscall+0x321
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp =
 0xbfbfe90c, ebp = 0xbfbfe928 ---
 db> show lockedvnods
 Locked vnodes
 
 0xc8761c3c: tag ufs, type VDIR
     usecount 1, writecount 0, refcount 1 mountedhere 0xc86cf2e4
     flags ()
      lock type ufs: EXCL (count 1) by thread 0xc8bac780 (pid 59934)#0
 0xc0668bf9 at lockmgr+0x4ed
 #1 0xc078572e at ffs_lock+0x76
 #2 0xc0838287 at VOP_LOCK_APV+0x87
 #3 0xc06d663c at vn_lock+0xac
 #4 0xc06c5eba at dounmount+0x62
 #5 0xc06c5e31 at unmount+0x1e5
 #6 0xc0825a07 at syscall+0x25b
 #7 0xc0811f7f at Xint0x80_syscall+0x1f
 
         ino 8260, on dev ufs/root
 
 0xc87b9414: tag ufs, type VDIR
     usecount 0, writecount 0, refcount 4 mountedhere 0
     flags (VV_ROOT)
     v_object 0xc8c43c60 ref 0 pages 1
      lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926)
 with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed
 #1 0xc078572e at ffs_lock+0x76
 #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 0xc07844af at ffs_vget+0x27
 #7 0xc078b253 at ufs_lookup+0xa4b
 #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
 
         ino 2, on dev da1s2e
 db> ps
   pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
 41369 75806 93096     0  R                           sleep
 59934 55518 59934     0  S+      vfslock  0xc86cf308 umount
 75806 62826 93096     0  R                           sh
 62826     1 93096     0  R                           sh
 39370     1 39370     0  Ss      ufs      0xc87b946c mountd
  6926     1  3231     0  R       CPU 1               nfsd
 
 So this seems to be umount and mountd tripping over each other.
 
 Uli

From: Kostik Belousov <kostikbel@gmail.com>
To: Ulrich Spoerlein <uspoerlein@gmail.com>
Cc: stable@freebsd.org, bug-followup@freebsd.org, rockowallaby@bellsouth.net,
        Mohan Srinivasan <mohans@freebsd.org>
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 15:15:45 +0200

 --TakKZr9L6Hm6aLOc
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Dec 15, 2006 at 01:44:23PM +0100, Ulrich Spoerlein wrote:
 > Hi,
 >=20
 > we too, ran into this problem. OS/2 Clients kill our NFS server. It is
 > running a RELENG_6 snapshot from 2006-11-14. rpc.lockd and rpc.statd
 > are running. I'll conduct a test without those two services shortly.
 >=20
 > You can still log in the system with ssh and cruse around, but mountd
 > is stuck in ufs state and is no longer serving requests.
 >=20
 > root@fs2:~# ps axl | grep ufs
 >    0 39370     1   0  -4  0  3052  2200 ufs    Ds    ??    0:00.01
 > /usr/sbin/mountd -r
 >=20
 > db> show lockedvnods
 > Locked vnodes
 >=20
 > 0xc87b9414: tag ufs, type VDIR
 >    usecount 0, writecount 0, refcount 4 mountedhere 0
 >    flags (VV_ROOT)
 >    v_object 0xc8c43c60 ref 0 pages 1
 >     lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926)
 > with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed
 > #1 0xc078572e at ffs_lock+0x76
 > #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 0xc07844af at ffs_vget+0x27
 > #7 0xc078b253 at ufs_lookup+0xa4b
 > #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
 >=20
 >        ino 2, on dev da1s2e
 >=20
 >=20
 > db> trace 6926
 > Tracing pid 6926 tid 100106 td 0xc8bac300
 > sched_switch(c8bac300,0,1) at sched_switch+0x177
 > mi_switch(1,0) at mi_switch+0x270
 > sleepq_switch(c8678200) at sleepq_switch+0xc1
 > sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d
 > msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a
 > nfssvc_nfsd(c8bac300) at nfssvc_nfsd+0xe5
 > nfssvc(c8bac300,eafd4d04) at nfssvc+0x18c
 > syscall(3b,3b,3b,1,0,...) at syscall+0x25b
 > Xint0x80_syscall() at Xint0x80_syscall+0x1f
 > --- syscall (155, FreeBSD ELF32, nfssvc), eip =3D 0x280bd1b7, esp =3D
 > 0xbfbfe90c, ebp =3D 0xbfbfe928 ---
 > db> trace 39370
 > Tracing pid 39370 tid 100102 td 0xc8bac900
 > sched_switch(c8bac900,0,1) at sched_switch+0x177
 > mi_switch(1,0) at mi_switch+0x270
 > sleepq_switch(c87b946c,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1
 > sleepq_wait(c87b946c,0,c87b94dc,b7,c08929b8,...) at sleepq_wait+0x46
 > msleep(c87b946c,c0972500,50,c089c1c1,0,...) at msleep+0x279
 > acquire(eafe094c,40,60000,c8bac900,0,...) at acquire+0x76
 > lockmgr(c87b946c,2002,c87b94dc,c8bac900) at lockmgr+0x44e
 > ffs_lock(eafe09a4) at ffs_lock+0x76
 > VOP_LOCK_APV(c0943320,eafe09a4) at VOP_LOCK_APV+0x87
 > vn_lock(c87b9414,2002,c8bac900,c87b9414) at vn_lock+0xac
 > vget(c87b9414,2002,c8bac900) at vget+0xc2
 > vfs_hash_get(c86cf2e4,2,2,c8bac900,eafe0abc,0,0) at vfs_hash_get+0x8d
 > ffs_vget(c86cf2e4,2,2,eafe0abc) at ffs_vget+0x27
 > ufs_root(c86cf2e4,2,eafe0b00,c8bac900,0,...) at ufs_root+0x19
 > lookup(eafe0ba0) at lookup+0x743
 > namei(eafe0ba0) at namei+0x39a
 > kern_lstat(c8bac900,bfbfd2a0,0,eafe0c74) at kern_lstat+0x47
 > lstat(c8bac900,eafe0d04) at lstat+0x1b
 > syscall(3b,3b,3b,281512fb,bfbfc9f1,...) at syscall+0x25b
 > Xint0x80_syscall() at Xint0x80_syscall+0x1f
 > --- syscall (190, FreeBSD ELF32, lstat), eip =3D 0x2813d427, esp =3D
 > 0xbfbfc5ac, ebp =3D 0xbfbfd268 ---
 >=20
 > I was under the impression, that you are not allowed to sleep while
 > holding a lock in the FreeBSD kernel. Doesn't this also apply to the
 > lockmgr itself?
 >=20
 > Upon shutting down the system, I had a panic coming in:
 >=20
 > panic: userret: Returning with 4 locks held.
 > cpuid =3D 1
 > KDB: stack backtrace:
 > kdb_backtrace(100,c8bac300,c8bac3c8,c8bad218,c8bac300,...) at=20
 > kdb_backtrace+0x29
 > panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x114
 > userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183
 > syscall(3b,3b,3b,1,0,...) at syscall+0x321
 > Xint0x80_syscall() at Xint0x80_syscall+0x1f
 > --- syscall (0, FreeBSD ELF32, nosys), eip =3D 0x280bd1b7, esp =3D
 > 0xbfbfe90c, ebp =3D 0xbfbfe928 ---
 > KDB: enter: panic
 > [thread pid 6926 tid 100106 ]
 > Stopped at      kdb_enter+0x2b: nop
 > db> bt
 > Tracing pid 6926 tid 100106 td 0xc8bac300
 > kdb_enter(c0894aec) at kdb_enter+0x2b
 > panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x127
 > userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183
 > syscall(3b,3b,3b,1,0,...) at syscall+0x321
 > Xint0x80_syscall() at Xint0x80_syscall+0x1f
 > --- syscall (0, FreeBSD ELF32, nosys), eip =3D 0x280bd1b7, esp =3D
 > 0xbfbfe90c, ebp =3D 0xbfbfe928 ---
 > db> show lockedvnods
 > Locked vnodes
 >=20
 > 0xc8761c3c: tag ufs, type VDIR
 >    usecount 1, writecount 0, refcount 1 mountedhere 0xc86cf2e4
 >    flags ()
 >     lock type ufs: EXCL (count 1) by thread 0xc8bac780 (pid 59934)#0
 > 0xc0668bf9 at lockmgr+0x4ed
 > #1 0xc078572e at ffs_lock+0x76
 > #2 0xc0838287 at VOP_LOCK_APV+0x87
 > #3 0xc06d663c at vn_lock+0xac
 > #4 0xc06c5eba at dounmount+0x62
 > #5 0xc06c5e31 at unmount+0x1e5
 > #6 0xc0825a07 at syscall+0x25b
 > #7 0xc0811f7f at Xint0x80_syscall+0x1f
 >=20
 >        ino 8260, on dev ufs/root
 >=20
 > 0xc87b9414: tag ufs, type VDIR
 >    usecount 0, writecount 0, refcount 4 mountedhere 0
 >    flags (VV_ROOT)
 >    v_object 0xc8c43c60 ref 0 pages 1
 >     lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926)
 > with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed
 > #1 0xc078572e at ffs_lock+0x76
 > #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 0xc07844af at ffs_vget+0x27
 > #7 0xc078b253 at ufs_lookup+0xa4b
 > #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
 >=20
 >        ino 2, on dev da1s2e
 > db> ps
 >  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
 > 41369 75806 93096     0  R                           sleep
 > 59934 55518 59934     0  S+      vfslock  0xc86cf308 umount
 > 75806 62826 93096     0  R                           sh
 > 62826     1 93096     0  R                           sh
 > 39370     1 39370     0  Ss      ufs      0xc87b946c mountd
 > 6926     1  3231     0  R       CPU 1               nfsd
 >=20
 > So this seems to be umount and mountd tripping over each other.
 >=20
 > Uli
 
 This looks like lock leak in nfsd. Could you supply the tcpdump of the
 session that causes the problem ? Also, it would be very helpful if you cou=
 ld
 note exact rpc that wedges the server.
 
 --TakKZr9L6Hm6aLOc
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (FreeBSD)
 
 iD8DBQFFgqAAC3+MBN1Mb4gRAsr0AKC+zN6OykbDcH2dGHazulrBruq0ewCgwKTu
 zsHKtcnJhnFSFJ2S4a989YA=
 =QZC9
 -----END PGP SIGNATURE-----
 
 --TakKZr9L6Hm6aLOc--

From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: "Kostik Belousov" <kostikbel@gmail.com>
Cc: stable@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 15:12:58 +0100

 On 12/15/06, Kostik Belousov <kostikbel@gmail.com> wrote:
 > This looks like lock leak in nfsd. Could you supply the tcpdump of the
 > session that causes the problem ? Also, it would be very helpful if you could
 > note exact rpc that wedges the server.
 
 That would have been my next step. I ran only rpcbind, nfsd and mountd
 on the file server (no rpc.lockd/rpc.statd). I then had an OS/2 Client
 mount the filesystem, issue a readdir and then tried to mount the same
 share from an Linux client. This last mount request never came back,
 immediately after issueing the mount request the mountd got stuck in
 state 'ufs' as shown in the backtrace.
 
 A tcpdump of the session can be found at:
 http://coyote.dnsalias.net/rpc.pcap (9kB)
 
 Uli
 
 PS: Please trim the Email when responding to the GNATS DB as that
 makes the PR-Trail rather unreadable. Thanks!

From: Kostik Belousov <kostikbel@gmail.com>
To: Ulrich Spoerlein <uspoerlein@gmail.com>
Cc: stable@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 16:28:09 +0200

 --raC6veAxrt5nqIoY
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Dec 15, 2006 at 03:12:58PM +0100, Ulrich Spoerlein wrote:
 > A tcpdump of the session can be found at:
 > http://coyote.dnsalias.net/rpc.pcap (9kB)
 >=20
 Am I right that all you did was ls -l <root of nfs mount> ? Does OS/2
 supports the notion of ".." directory ? Could you do just "ls -l .."
 from nfs client and then try "stat <root of exported fs>" on the server
 (i think it shall hang) ?
 
 My hypothesis is that LOOKUP RPC for ".." causes directory vnode lock
 leak in nfs_namei. After that, mountd hang is just consequence.
 
 --raC6veAxrt5nqIoY
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (FreeBSD)
 
 iD8DBQFFgrD4C3+MBN1Mb4gRAtiqAJ9EsyTLBk7IwXw7vJuc41xgCX/xtACgiH4L
 g8t6UNjdVFLfMKKJIgnsC6E=
 =OJqq
 -----END PGP SIGNATURE-----
 
 --raC6veAxrt5nqIoY--

From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: "Kostik Belousov" <kostikbel@gmail.com>
Cc: stable@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 16:18:32 +0100

 On 12/15/06, Kostik Belousov <kostikbel@gmail.com> wrote:
 > Am I right that all you did was ls -l <root of nfs mount> ? Does OS/2
 > supports the notion of ".." directory ? Could you do just "ls -l .."
 > from nfs client and then try "stat <root of exported fs>" on the server
 > (i think it shall hang) ?
 
 Yes, you are right about the symptoms. We tried the following on the OS/2 Client
 
 mount export
 umount export
 mount export
 umount export
 
 this is all working fine, then we do a "dir" on the mounted FS
 
 mount i: /export/foo
 dir i:
 umount  <-- haning, as mountd can't process the RPC.
 
 > My hypothesis is that LOOKUP RPC for ".." causes directory vnode lock
 > leak in nfs_namei. After that, mountd hang is just consequence.
 
 So, I mounted from the OS/2 Client, ran a dir on the i: drive and then
 an stat(1) to the exported partition on the server. This stat would
 hang, here's the backtraces:
 db> ps
   pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
 33017 88035 33017     0  S+      ufs      0xc8771880 stat
 23627 55476 23627     0  S+      bpf      0xc8e16c00 tcpdump
 88035 87505 88035     0  S+      pause    0xc882bcc4 tcsh
 87505 72558 87505  1000  S+      wait     0xc86f9218 su
 72558 89630 72558  1000  Ss+     pause    0xc873867c tcsh
 21229     1 21229     0  Ss      select   0xc09c10c4 mountd
 91293 79042 79042     0  S       -        0xc8668200 nfsd
 88479 79042 79042     0  S       -        0xc8668600 nfsd
 86952 79042 79042     0  S       -        0xc847cc00 nfsd
 83659 79042 79042     0  S       -        0xc8678200 nfsd
 79042     1 79042     0  Ss      accept   0xc8d649f6 nfsd
 55476 52005 55476     0  S+      pause    0xc8bcc24c tcsh
 52005 95193 52005  1000  S+      wait     0xc8734648 su
 ...
 db> show lockedvnods
 Locked vnodes
 
 0xc8771828: tag ufs, type VDIR
     usecount 0, writecount 0, refcount 4 mountedhere 0
     flags (VV_ROOT)
     v_object 0xc8a8a084 ref 0 pages 1
      lock type ufs: EXCL (count 1) by thread 0xc882f900 (pid 83659)
 with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed
 #1 0xc078572e at ffs_lock+0x76
 #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 0xc07844af at ffs_vget+0x27
 #7 0xc078b253 at ufs_lookup+0xa4b
 #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
 
         ino 2, on dev da1s2e
 db> tr 33017
 Tracing pid 33017 tid 100125 td 0xc86fd600
 sched_switch(c86fd600,0,1) at sched_switch+0x177
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c8771880,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1
 sleepq_wait(c8771880,0,c87718f0,b7,c08929b8,...) at sleepq_wait+0x46
 msleep(c8771880,c0972590,50,c089c1c1,0,...) at msleep+0x279
 acquire(eb01694c,40,60000,c86fd600,0,...) at acquire+0x76
 lockmgr(c8771880,2002,c87718f0,c86fd600) at lockmgr+0x44e
 ffs_lock(eb0169a4) at ffs_lock+0x76
 VOP_LOCK_APV(c0943320,eb0169a4) at VOP_LOCK_APV+0x87
 vn_lock(c8771828,2002,c86fd600,c8771828) at vn_lock+0xac
 vget(c8771828,2002,c86fd600) at vget+0xc2
 vfs_hash_get(c87115c8,2,2,c86fd600,eb016abc,0,0) at vfs_hash_get+0x8d
 ffs_vget(c87115c8,2,2,eb016abc) at ffs_vget+0x27
 ufs_root(c87115c8,2,eb016b00,c86fd600,0,...) at ufs_root+0x19
 lookup(eb016ba0) at lookup+0x743
 namei(eb016ba0) at namei+0x39a
 kern_lstat(c86fd600,bfbfed99,0,eb016c74) at kern_lstat+0x47
 lstat(c86fd600,eb016d04) at lstat+0x1b
 syscall(3b,3b,3b,0,bfbfebf0,...) at syscall+0x25b
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2812d427, esp =
 0xbfbfeb9c, ebp = 0xbfbfec68 ---
 db> tr 83659
 Tracing pid 83659 tid 100115 td 0xc882f900
 sched_switch(c882f900,0,1) at sched_switch+0x177
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c8678200) at sleepq_switch+0xc1
 sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d
 msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a
 nfssvc_nfsd(c882f900) at nfssvc_nfsd+0xe5
 nfssvc(c882f900,eaf8ad04) 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 ---
 
 Do you think you can fix it? Any idea why this seems to only happen
 with OS/2 Clients?
 
 Uli

From: Kostik Belousov <kostikbel@gmail.com>
To: Ulrich Spoerlein <uspoerlein@gmail.com>
Cc: stable@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Fri, 15 Dec 2006 17:27:30 +0200

 --q9KOos5vDmpwPx9o
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Dec 15, 2006 at 04:18:32PM +0100, Ulrich Spoerlein wrote:
 [Lot of debugging info trimmed to pacify you ]
 >=20
 > Do you think you can fix it? Any idea why this seems to only happen
 > with OS/2 Clients?
 
 It seems that my guess is right. OS/2 nfs client, in contrast to unix clien=
 t,
 send LOOKUP ".." on the root vnode to the server.
 
 
 --q9KOos5vDmpwPx9o
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (FreeBSD)
 
 iD8DBQFFgr7hC3+MBN1Mb4gRAh1NAJ979NHf5n/MUktAyXmT1cJXXrN5lwCcDDk9
 lRiefyReuh2hWGXOknjPHZA=
 =jFKP
 -----END PGP SIGNATURE-----
 
 --q9KOos5vDmpwPx9o--

From: John Merryweather Cooper <john_m_cooper@yahoo.com>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: Ulrich Spoerlein <uspoerlein@gmail.com>,  stable@freebsd.org, 
 bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes
 filesystem freeze
Date: Fri, 15 Dec 2006 19:54:25 -0500

 Kostik Belousov wrote:
 > On Fri, Dec 15, 2006 at 03:12:58PM +0100, Ulrich Spoerlein wrote:
 >   
 >> A tcpdump of the session can be found at:
 >> http://coyote.dnsalias.net/rpc.pcap (9kB)
 >>
 >>     
 > Am I right that all you did was ls -l <root of nfs mount> ? Does OS/2
 > supports the notion of ".." directory ? Could you do just "ls -l .."
 > from nfs client and then try "stat <root of exported fs>" on the server
 > (i think it shall hang) ?
 >
 > My hypothesis is that LOOKUP RPC for ".." causes directory vnode lock
 > leak in nfs_namei. After that, mountd hang is just consequence.
 >   
 Yes, OS/2 supports the ".." directory.  FAT, HPFS, and JFS all have a 
 ".." directory.
 
 jmc
 

From: Bruce Evans <bde@zeta.org.au>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes
 filesystem freeze
Date: Sat, 16 Dec 2006 17:16:58 +1100 (EST)

 On Fri, 15 Dec 2006, Kostik Belousov wrote:
 
 > Am I right that all you did was ls -l <root of nfs mount> ? Does OS/2
 > supports the notion of ".." directory ? Could you do just "ls -l .."
 > from nfs client and then try "stat <root of exported fs>" on the server
 > (i think it shall hang) ?
 >
 > My hypothesis is that LOOKUP RPC for ".." causes directory vnode lock
 > leak in nfs_namei. After that, mountd hang is just consequence.
 
 Is this related to rev.1.103 of vfs_cache.c?  That commit turns off
 caching of ".." in most (?) cases.  This gives an especially large
 pessimization for nfs since for nfs there is no chance that ".." is
 cached elsewhere in the kernel, so physical i/o is always required to
 look up "..".  I run with this commit backed out and haven't noticed
 any problems (but it seems to only be needed for the unusual operation
 of removing active current directories).
 
 Bruce.

From: Ulrich Spoerlein <uspoerlein@gmail.com>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Date: Mon, 18 Dec 2006 16:08:34 +0100

 Konstantin Belousov wrote:
 > Try this (not ever booted kernel with this patch applied, beware).
 > 
 > Index: ufs/ufs/ufs_lookup.c
 > ===================================================================
 > RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v
 > retrieving revision 1.82
 > diff -u -r1.82 ufs_lookup.c
 > --- ufs/ufs/ufs_lookup.c	31 Jul 2006 15:44:13 -0000	1.82
 > +++ ufs/ufs/ufs_lookup.c	15 Dec 2006 15:42:43 -0000
 > @@ -556,7 +553,10 @@
 >  	 * that point backwards in the directory structure.
 >  	 */
 >  	pdp = vdp;
 > -	if (flags & ISDOTDOT) {
 > +	if (dp->i_number == dp->i_ino) {
 > +		VREF(vdp);	/* we want ourself, ie "." */
 > +		*vpp = vdp;
 > +	} else if (flags & ISDOTDOT) {
 >  		saved_ino = dp->i_ino;
 >  		VOP_UNLOCK(pdp, 0, td);	/* race to get the inode */
 >  		error = VFS_VGET(pdp->v_mount, saved_ino,
 > @@ -565,9 +565,6 @@
 >  		if (error)
 >  			return (error);
 >  		*vpp = tdp;
 > -	} else if (dp->i_number == dp->i_ino) {
 > -		VREF(vdp);	/* we want ourself, ie "." */
 > -		*vpp = vdp;
 >  	} else {
 >  		error = VFS_VGET(pdp->v_mount, dp->i_ino,
 >  		    cnp->cn_lkflags, &tdp);
 
 
 I had a colleague of mine test this while instructing him over the phone
 and it seems to fix the problem. No deadlocks, no leaks, the OS/2
 clients can mount/ls/umount at will. All seems well.
 
 Extensive tests have NOT yet been done. I'm also a little uneasy, as the
 patch changes code that has been there since revision 1.1. I wonder how
 4.x managed these OS/2 clients. Perhaps the old nfsd/rpc code rejected
 these bogus lookups?
 
 Anyway, thank you very much for the patch, we will be running it on our
 server base shortly.
 
 Ulrich Spoerlein
 
 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.

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

From: Kostik Belousov <kostikbel@gmail.com>
To: Ulrich Spoerlein <uspoerlein@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 12:59:40 +0200

 --0aF+6pWUK5w8WdCh
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Dec 27, 2006 at 11:43:36AM +0100, Ulrich Spoerlein wrote:
 > 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.
 >=20
 > panic: lockmgr: locking against myself
 
 I did not read the code thoroughly, and I prefer not to touch
 msdosfs. But, anyway, try this:
 
 Index: sys/fs/msdosfs/msdosfs_lookup.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /usr/local/arch/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v
 retrieving revision 1.47
 diff -u -r1.47 msdosfs_lookup.c
 --- sys/fs/msdosfs/msdosfs_lookup.c	22 Jan 2006 21:09:38 -0000	1.47
 +++ sys/fs/msdosfs/msdosfs_lookup.c	27 Dec 2006 10:59:17 -0000
 @@ -520,16 +520,16 @@
  	 * that point backwards in the directory structure.
  	 */
  	pdp =3D vdp;
 -	if (flags & ISDOTDOT) {
 +	if (dp->de_StartCluster =3D=3D scn && isadir) {
 +		VREF(vdp);	/* we want ourself, ie "." */
 +		*vpp =3D vdp;
 +	} else if (flags & ISDOTDOT) {
  		VOP_UNLOCK(pdp, 0, td);
  		error =3D deget(pmp, cluster, blkoff,  &tdp);
  		vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td);=20
  		if (error)
  			return (error);
  		*vpp =3D DETOV(tdp);
 -	} else if (dp->de_StartCluster =3D=3D scn && isadir) {
 -		VREF(vdp);	/* we want ourself, ie "." */
 -		*vpp =3D vdp;
  	} else {
  		if ((error =3D deget(pmp, cluster, blkoff, &tdp)) !=3D 0)
  			return (error);
 
 --0aF+6pWUK5w8WdCh
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (FreeBSD)
 
 iD8DBQFFklIcC3+MBN1Mb4gRAlT9AJ0b8N2DP+GPnC6r8s1Kbsq7pvDDpACgiD8g
 38i7NiuxiHwlsG+7Olp9wCo=
 =FMmX
 -----END PGP SIGNATURE-----
 
 --0aF+6pWUK5w8WdCh--

From: Bruce Evans <bde@zeta.org.au>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: Ulrich Spoerlein <uspoerlein@gmail.com>, bug-followup@FreeBSD.org
Subject: Re: kern/92785: Using exported filesystem on OS/2 NFS client causes
 filesystem freeze
Date: Thu, 28 Dec 2006 01:02:20 +1100 (EST)

 On Wed, 27 Dec 2006, Kostik Belousov wrote:
 
 > On Wed, Dec 27, 2006 at 11:43:36AM +0100, Ulrich Spoerlein wrote:
 >> 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
 >
 > I did not read the code thoroughly, and I prefer not to touch
 > msdosfs. But, anyway, try this:
 
 Me too.
 
 > Index: sys/fs/msdosfs/msdosfs_lookup.c
 > ===================================================================
 > RCS file: /usr/local/arch/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v
 > retrieving revision 1.47
 > diff -u -r1.47 msdosfs_lookup.c
 > --- sys/fs/msdosfs/msdosfs_lookup.c	22 Jan 2006 21:09:38 -0000	1.47
 > +++ sys/fs/msdosfs/msdosfs_lookup.c	27 Dec 2006 10:59:17 -0000
 > @@ -520,16 +520,16 @@
 > 	 * that point backwards in the directory structure.
 > 	 */
 > 	pdp = vdp;
 > -	if (flags & ISDOTDOT) {
 > +	if (dp->de_StartCluster == scn && isadir) {
 > +		VREF(vdp);	/* we want ourself, ie "." */
 > +		*vpp = vdp;
 > +	} else if (flags & ISDOTDOT) {
 > 		VOP_UNLOCK(pdp, 0, td);
 > 		error = deget(pmp, cluster, blkoff,  &tdp);
 > 		vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td);
 > 		if (error)
 > 			return (error);
 > 		*vpp = DETOV(tdp);
 > -	} else if (dp->de_StartCluster == scn && isadir) {
 > -		VREF(vdp);	/* we want ourself, ie "." */
 > -		*vpp = vdp;
 > 	} else {
 > 		if ((error = deget(pmp, cluster, blkoff, &tdp)) != 0)
 > 			return (error);
 >
 
 Funny, this looks like a bug that was first reported for msdosfs.  Here
 is some old mail about it.
 
 From bde@zeta.org.au Sun Aug  6 09:59:24 2006 +1000
 Date: Sun, 6 Aug 2006 09:59:22 +1000 (EST)
 From: Bruce Evans <bde@zeta.org.au>
 X-X-Sender: bde@delplex.bde.org
 To: Michiel Pelt <pelt22@gmail.com>
 cc: freebsd-fs@freebsd.org
 Subject: Re: VOP_LOOKUP of .. in msdosfs
 In-Reply-To: <cee5e2ee0608050817u67f0c08cw73ec68f54400375b@mail.gmail.com>
 Message-ID: <20060806094905.V2709@delplex.bde.org>
 References: <cee5e2ee0608050817u67f0c08cw73ec68f54400375b@mail.gmail.com>
 MIME-Version: 1.0
 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
 Status: O
 X-Status: 
 X-Keywords: 
 X-UID: 360
 
 On Sat, 5 Aug 2006, Michiel Pelt wrote:
 
 > ...
 > The msdosfs_lookup function in msdosfs_lookup.c has code dealing with the
 > rootdirectory at the label foundroot:. At line 523 (release 6.1 code) of the
 > release code is this piece of code:
 >
 > pdp = vdp;
 > if (flags & ISDOTDOT) {
 >  VOP_UNLOCK(pdp, 0, td);
 >  error = deget(pmp, cluster, blkoff, &tdp);
 >  vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td);
 >  if (error)
 >     return (error);
 >  *vpp = DETOV(tdp);
 > }
 >
 > This code has been copied from ffs code, but fails for msdosfs.
 > For starters the introduction of the 'pdp' pointer has no function
 > whatsoever.
 >
 > Consider a lookup for .. in the root. In msdosfs the /. and /.. directories
 > are represented by one and the same vnode (see deget() in msdosfs_denode.c).
 > The deget gets and locks the vnode that was unlocked by VOP_UNLOCK. The
 > vn_lock that follows fails with a panic because the vnode is already locked.
 
 It seems to have been correct in 5.2:
 
 % 	pdp = vdp;
 % 	if (flags & ISDOTDOT) {
 % 		VOP_UNLOCK(pdp, 0, td);
 % 		cnp->cn_flags |= PDIRUNLOCK;
 % 		error = deget(pmp, cluster, blkoff,  &tdp);
 % 		if (error) {
 % 			vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); 
 % 			cnp->cn_flags &= ~PDIRUNLOCK;
 % 			return (error);
 % 		}
 
 Apparently, deget() didn't lock, and we only needed to lock in the error
 case.  Or maybe the problem went unnoticed because the error case is
 even rarer than the ISDOTDOT case.
 
 > So why does this not happen in practice? Because the ISDOTDOT case is
 > handled by vfs_lookup and never reaches VOP_LOOKUP.
 >
 > I did get the error because I forgot to set the VV_ROOT flag in the vnode
 > returned by VFS_ROOT ;-(.
 
 I think the whole ISDOTDOT case is unreachable for the root of an
 msdosfs file system, at least in 5.2, since msdosfs can't be mounted
 on "/" so ".." at the root is never in the current file system and so
 it must be handled by vfs_lookup() and VFS_ROOT must be set so that
 it is handled there.
 
 Bruce
 
 %%%
 
 I don't understand the changes near here since 5.2 (even in ffs).  If
 you do, then please touch a lot of file systems that have the bug :-).
 
 Bruce

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 17:05:00 +0100

 ------=_Part_125620_18226065.1167235500867
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 On 12/27/06, Konstantin Belousov <kostikbel@gmail.com> wrote:
 > Index: fs/udf/udf_vnops.c
 > ===================================================================
 > RCS file: /usr/local/arch/ncvs/src/sys/fs/udf/udf_vnops.c,v
 > retrieving revision 1.61
 > diff -u -r1.61 udf_vnops.c
 > --- fs/udf/udf_vnops.c  3 Feb 2006 15:25:52 -0000       1.61
 > +++ fs/udf/udf_vnops.c  27 Dec 2006 15:24:10 -0000
 > @@ -915,7 +915,7 @@
 >                 if (flags & ISDOTDOT)
 >                         VOP_UNLOCK(dvp, 0, a->a_cnp->cn_thread);
 >                 error = udf_vget(udfmp->im_mountp, id, LK_EXCLUSIVE, &tdp);
 > -               if (flags & ISDOTDOT)
 > +               if ((flags & ISDOTDOT) && dvp != tdp )
 >                         vn_lock(dvp, LK_EXCLUSIVE|LK_RETRY, a->a_cnp->cn_thread);
 >                 if (!error) {
 >                         /*
 
 I do NOT have a UDF-Image and can thus not test this change. If some
 kind soul could give me a link to an UDF image < 300MB, that would be
 great.
 
 In addition to ufs, msdosfs and cd9660, I also had to patch ext2fs in
 the same way. NB: Even though reiserfs has a similar code flow, I was
 not able to make a reiserfs exported filesystem hang or crash the
 machine. Odd.
 
 Attached is the cumulative diff of the kernel I tested this with.
 Tested filesystems needing patch: ufs, msdosfs, cd9660, ext2fs
 Tested filesystems sans patch: reiserfs
 Untested filesystems: udf, ntfs, smbfs, nwfs, (zfs?)
 
 All the testing was sponsored by: 1822direkt GmbH
 Thanks for your support.
 
 Uli
 
 ------=_Part_125620_18226065.1167235500867
 Content-Type: text/x-patch; name=lookup.diff; charset=ANSI_X3.4-1968
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_ew7xu9sx
 Content-Disposition: attachment; filename="lookup.diff"
 
 SW5kZXg6IGZzL21zZG9zZnMvbXNkb3Nmc19sb29rdXAuYwo9PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAv
 YnVpbGQvbmN2cy9zcmMvc3lzL2ZzL21zZG9zZnMvbXNkb3Nmc19sb29rdXAuYyx2CnJldHJpZXZp
 bmcgcmV2aXNpb24gMS40NgpkaWZmIC11IC1yMS40NiBtc2Rvc2ZzX2xvb2t1cC5jCi0tLSBmcy9t
 c2Rvc2ZzL21zZG9zZnNfbG9va3VwLmMJMTYgQXByIDIwMDUgMjM6NDc6MTkgLTAwMDAJMS40Ngor
 KysgZnMvbXNkb3Nmcy9tc2Rvc2ZzX2xvb2t1cC5jCTI3IERlYyAyMDA2IDEzOjA2OjA2IC0wMDAw
 CkBAIC01MjAsMTYgKzUyMCwxNiBAQAogCSAqIHRoYXQgcG9pbnQgYmFja3dhcmRzIGluIHRoZSBk
 aXJlY3Rvcnkgc3RydWN0dXJlLgogCSAqLwogCXBkcCA9IHZkcDsKLQlpZiAoZmxhZ3MgJiBJU0RP
 VERPVCkgeworCWlmIChkcC0+ZGVfU3RhcnRDbHVzdGVyID09IHNjbiAmJiBpc2FkaXIpIHsKKwkJ
 VlJFRih2ZHApOwkvKiB3ZSB3YW50IG91cnNlbGYsIGllICIuIiAqLworCQkqdnBwID0gdmRwOwor
 CX0gZWxzZSBpZiAoZmxhZ3MgJiBJU0RPVERPVCkgewogCQlWT1BfVU5MT0NLKHBkcCwgMCwgdGQp
 OwogCQllcnJvciA9IGRlZ2V0KHBtcCwgY2x1c3RlciwgYmxrb2ZmLCAgJnRkcCk7CiAJCXZuX2xv
 Y2socGRwLCBMS19FWENMVVNJVkUgfCBMS19SRVRSWSwgdGQpOyAKIAkJaWYgKGVycm9yKQogCQkJ
 cmV0dXJuIChlcnJvcik7CiAJCSp2cHAgPSBERVRPVih0ZHApOwotCX0gZWxzZSBpZiAoZHAtPmRl
 X1N0YXJ0Q2x1c3RlciA9PSBzY24gJiYgaXNhZGlyKSB7Ci0JCVZSRUYodmRwKTsJLyogd2Ugd2Fu
 dCBvdXJzZWxmLCBpZSAiLiIgKi8KLQkJKnZwcCA9IHZkcDsKIAl9IGVsc2UgewogCQlpZiAoKGVy
 cm9yID0gZGVnZXQocG1wLCBjbHVzdGVyLCBibGtvZmYsICZ0ZHApKSAhPSAwKQogCQkJcmV0dXJu
 IChlcnJvcik7CkluZGV4OiBnbnUvZnMvZXh0MmZzL2V4dDJfbG9va3VwLmMKPT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpS
 Q1MgZmlsZTogL2J1aWxkL25jdnMvc3JjL3N5cy9nbnUvZnMvZXh0MmZzL2V4dDJfbG9va3VwLmMs
 dgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNTAuMi4xCmRpZmYgLXUgLXIxLjUwLjIuMSBleHQyX2xv
 b2t1cC5jCi0tLSBnbnUvZnMvZXh0MmZzL2V4dDJfbG9va3VwLmMJNCBKYW4gMjAwNiAxOTozMjow
 MCAtMDAwMAkxLjUwLjIuMQorKysgZ251L2ZzL2V4dDJmcy9leHQyX2xvb2t1cC5jCTI3IERlYyAy
 MDA2IDE1OjI2OjAxIC0wMDAwCkBAIC02NTUsNyArNjU1LDEwIEBACiAJICogdGhhdCBwb2ludCBi
 YWNrd2FyZHMgaW4gdGhlIGRpcmVjdG9yeSBzdHJ1Y3R1cmUuCiAJICovCiAJcGRwID0gdmRwOwot
 CWlmIChmbGFncyAmIElTRE9URE9UKSB7CisJaWYgKGRwLT5pX251bWJlciA9PSBkcC0+aV9pbm8p
 IHsKKwkJVlJFRih2ZHApOwkvKiB3ZSB3YW50IG91cnNlbGYsIGllICIuIiAqLworCQkqdnBwID0g
 dmRwOworCX0gZWxzZSBpZiAoZmxhZ3MgJiBJU0RPVERPVCkgewogCQlzYXZlZF9pbm8gPSBkcC0+
 aV9pbm87CiAJCVZPUF9VTkxPQ0socGRwLCAwLCB0ZCk7CS8qIHJhY2UgdG8gZ2V0IHRoZSBpbm9k
 ZSAqLwogCQllcnJvciA9IFZGU19WR0VUKHZkcC0+dl9tb3VudCwgc2F2ZWRfaW5vLCBMS19FWENM
 VVNJVkUsICZ0ZHApOwpAQCAtNjYzLDkgKzY2Niw2IEBACiAJCWlmIChlcnJvciAhPSAwKQogCQkJ
 cmV0dXJuIChlcnJvcik7CiAJCSp2cHAgPSB0ZHA7Ci0JfSBlbHNlIGlmIChkcC0+aV9udW1iZXIg
 PT0gZHAtPmlfaW5vKSB7Ci0JCVZSRUYodmRwKTsJLyogd2Ugd2FudCBvdXJzZWxmLCBpZSAiLiIg
 Ki8KLQkJKnZwcCA9IHZkcDsKIAl9IGVsc2UgewogCQlpZiAoKGVycm9yID0gVkZTX1ZHRVQodmRw
 LT52X21vdW50LCBkcC0+aV9pbm8sIExLX0VYQ0xVU0lWRSwKIAkJICAgICZ0ZHApKSAhPSAwKQpJ
 bmRleDogaXNvZnMvY2Q5NjYwL2NkOTY2MF9sb29rdXAuYwo9PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAv
 YnVpbGQvbmN2cy9zcmMvc3lzL2lzb2ZzL2NkOTY2MC9jZDk2NjBfbG9va3VwLmMsdgpyZXRyaWV2
 aW5nIHJldmlzaW9uIDEuNDEuMi4xCmRpZmYgLXUgLXIxLjQxLjIuMSBjZDk2NjBfbG9va3VwLmMK
 LS0tIGlzb2ZzL2NkOTY2MC9jZDk2NjBfbG9va3VwLmMJNCBKYW4gMjAwNiAxOTozNToyNCAtMDAw
 MAkxLjQxLjIuMQorKysgaXNvZnMvY2Q5NjYwL2NkOTY2MF9sb29rdXAuYwkyNyBEZWMgMjAwNiAx
 MzozMToyNiAtMDAwMApAQCAtMzQ3LDcgKzM0NywxMSBAQAogCSAqIElmIGlubyBpcyBkaWZmZXJl
 bnQgZnJvbSBkcC0+aV9pbm8sCiAJICogaXQncyBhIHJlbG9jYXRlZCBkaXJlY3RvcnkuCiAJICov
 Ci0JaWYgKGZsYWdzICYgSVNET1RET1QpIHsKKwlpZiAoZHAtPmlfbnVtYmVyID09IGRwLT5pX2lu
 bykgeworCQlicmVsc2UoYnApOworCQlWUkVGKHZkcCk7CS8qIHdlIHdhbnQgb3Vyc2VsZiwgaWUg
 Ii4iICovCisJCSp2cHAgPSB2ZHA7CisJfSBlbHNlIGlmIChmbGFncyAmIElTRE9URE9UKSB7CiAJ
 CXNhdmVkX2lubyA9IGRwLT5pX2lubzsKIAkJVk9QX1VOTE9DSyhwZHAsIDAsIHRkKTsJLyogcmFj
 ZSB0byBnZXQgdGhlIGlub2RlICovCiAJCWVycm9yID0gY2Q5NjYwX3ZnZXRfaW50ZXJuYWwodmRw
 LT52X21vdW50LCBzYXZlZF9pbm8sCkBAIC0zNTgsMTAgKzM2Miw2IEBACiAJCWlmIChlcnJvcikK
 IAkJCXJldHVybiAoZXJyb3IpOwogCQkqdnBwID0gdGRwOwotCX0gZWxzZSBpZiAoZHAtPmlfbnVt
 YmVyID09IGRwLT5pX2lubykgewotCQlicmVsc2UoYnApOwotCQlWUkVGKHZkcCk7CS8qIHdlIHdh
 bnQgb3Vyc2VsZiwgaWUgIi4iICovCi0JCSp2cHAgPSB2ZHA7CiAJfSBlbHNlIHsKIAkJZXJyb3Ig
 PSBjZDk2NjBfdmdldF9pbnRlcm5hbCh2ZHAtPnZfbW91bnQsIGRwLT5pX2lubywKIAkJCQkJICAg
 ICBMS19FWENMVVNJVkUsICZ0ZHAsCkluZGV4OiB1ZnMvdWZzL3Vmc19sb29rdXAuYwo9PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09ClJDUyBmaWxlOiAvYnVpbGQvbmN2cy9zcmMvc3lzL3Vmcy91ZnMvdWZzX2xvb2t1cC5jLHYK
 cmV0cmlldmluZyByZXZpc2lvbiAxLjc3LjIuMwpkaWZmIC11IC1yMS43Ny4yLjMgdWZzX2xvb2t1
 cC5jCi0tLSB1ZnMvdWZzL3Vmc19sb29rdXAuYwk1IFNlcCAyMDA2IDEzOjIwOjQxIC0wMDAwCTEu
 NzcuMi4zCisrKyB1ZnMvdWZzL3Vmc19sb29rdXAuYwkyNyBEZWMgMjAwNiAxMjo1MTozMiAtMDAw
 MApAQCAtNTU2LDcgKzU1NiwxMCBAQAogCSAqIHRoYXQgcG9pbnQgYmFja3dhcmRzIGluIHRoZSBk
 aXJlY3Rvcnkgc3RydWN0dXJlLgogCSAqLwogCXBkcCA9IHZkcDsKLQlpZiAoZmxhZ3MgJiBJU0RP
 VERPVCkgeworCWlmIChkcC0+aV9udW1iZXIgPT0gZHAtPmlfaW5vKSB7CisJCVZSRUYodmRwKTsJ
 Lyogd2Ugd2FudCBvdXJzZWxmLCBpZSAiLiIgKi8KKwkJKnZwcCA9IHZkcDsKKwl9IGVsc2UgaWYg
 KGZsYWdzICYgSVNET1RET1QpIHsKIAkJc2F2ZWRfaW5vID0gZHAtPmlfaW5vOwogCQlWT1BfVU5M
 T0NLKHBkcCwgMCwgdGQpOwkvKiByYWNlIHRvIGdldCB0aGUgaW5vZGUgKi8KIAkJZXJyb3IgPSBW
 RlNfVkdFVChwZHAtPnZfbW91bnQsIHNhdmVkX2lubywKQEAgLTU2NSw5ICs1NjgsNiBAQAogCQlp
 ZiAoZXJyb3IpCiAJCQlyZXR1cm4gKGVycm9yKTsKIAkJKnZwcCA9IHRkcDsKLQl9IGVsc2UgaWYg
 KGRwLT5pX251bWJlciA9PSBkcC0+aV9pbm8pIHsKLQkJVlJFRih2ZHApOwkvKiB3ZSB3YW50IG91
 cnNlbGYsIGllICIuIiAqLwotCQkqdnBwID0gdmRwOwogCX0gZWxzZSB7CiAJCWVycm9yID0gVkZT
 X1ZHRVQocGRwLT52X21vdW50LCBkcC0+aV9pbm8sCiAJCSAgICBjbnAtPmNuX2xrZmxhZ3MsICZ0
 ZHApOwo=
 ------=_Part_125620_18226065.1167235500867--

From: Kostik Belousov <kostikbel@gmail.com>
To: Ulrich Spoerlein <uspoerlein@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 18:17:07 +0200

 --1Dvf9Qz7hFaodvwE
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Wed, Dec 27, 2006 at 05:05:00PM +0100, Ulrich Spoerlein wrote:
 > Attached is the cumulative diff of the kernel I tested this with.
 > Tested filesystems needing patch: ufs, msdosfs, cd9660, ext2fs
 > Tested filesystems sans patch: reiserfs
 > Untested filesystems: udf, ntfs, smbfs, nwfs, (zfs?)
 
 The better change for UDF:
 
 Index: fs/udf/udf_vnops.c
 ===================================================================
 RCS file: /usr/local/arch/ncvs/src/sys/fs/udf/udf_vnops.c,v
 retrieving revision 1.61
 diff -u -r1.61 udf_vnops.c
 --- fs/udf/udf_vnops.c	3 Feb 2006 15:25:52 -0000	1.61
 +++ fs/udf/udf_vnops.c	27 Dec 2006 16:16:51 -0000
 @@ -915,7 +915,7 @@
  		if (flags & ISDOTDOT)
  			VOP_UNLOCK(dvp, 0, a->a_cnp->cn_thread);
  		error = udf_vget(udfmp->im_mountp, id, LK_EXCLUSIVE, &tdp);
 -		if (flags & ISDOTDOT)
 +		if ((flags & ISDOTDOT) && (dvp != tdp || error))
  			vn_lock(dvp, LK_EXCLUSIVE|LK_RETRY, a->a_cnp->cn_thread);
  		if (!error) {
  			/*
 
 --1Dvf9Qz7hFaodvwE
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (FreeBSD)
 
 iD8DBQFFkpyDC3+MBN1Mb4gRAvrRAJ9gle9FlZjtWW/HwO7B+/H0D9prKQCgknms
 p+CM6dkPOX7AF8Aq0aOhZOQ=
 =1sbA
 -----END PGP SIGNATURE-----
 
 --1Dvf9Qz7hFaodvwE--

From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: "Kostik 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: Thu, 28 Dec 2006 12:06:49 +0100

 On 12/27/06, Kostik Belousov <kostikbel@gmail.com> wrote:
 > The better change for UDF:
 
 The change for UDF is needed (panic otherwise) but it is NOT working.
 vn_lock() is still called and will panic, as it is locking against
 itself:
 panic: lockmgr: locking against myself
 cpuid = 1
 KDB: stack backtrace:
 kdb_backtrace(100,c8971780,3002,80,c8971780,...) at kdb_backtrace+0x29
 panic(c08904dc,c8971780,0,c090fa80,eaeec7d4,...) at panic+0x114
 lockmgr(c8d566b8,3002,c8d566dc,c8971780,eaeec7b4,...) at lockmgr+0x3da
 vop_stdlock(eaeec7d4) at vop_stdlock+0x1e
 VOP_LOCK_APV(c8d5e800,eaeec7d4) at VOP_LOCK_APV+0x87
 vn_lock(c8d56660,1002,c8971780,173,58,...) at vn_lock+0xa8
 udf_lookup(eaeec880) at udf_lookup+0x22e
 VOP_CACHEDLOOKUP_APV(c8d5e800,eaeec880) at VOP_CACHEDLOOKUP_APV+0x7e
 vfs_cache_lookup(eaeec91c) at vfs_cache_lookup+0xb2
 VOP_LOOKUP_APV(c8d5e800,eaeec91c) at VOP_LOOKUP_APV+0x87
 lookup(eaeecc0c) at lookup+0x456
 nfs_namei(eaeecc0c,eaeecb3c,2,c8c31e80,c8c1c1a0,eaeeca24,eaeeca28,eaeeca10,0,eaeeca5c,eaeeca14,c8971780,0,eaeecb3c)
 at nfs_namei+0x40e
 nfsrv_lookup(c8c18b00,c8c31e80,c8971780,eaeecc98) at nfsrv_lookup+0x1dd
 nfssvc_nfsd(c8971780) at nfssvc_nfsd+0x3d9
 nfssvc(c8971780,eaeecd04) at nfssvc+0x18c
 syscall(3b,3b,3b,1,0,...) at syscall+0x25b
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 
 
 I'm having trouble with NTFS, too. I created a small image with ntfs3g
 (which is known to DTRT most of the time). Accessing this image
 locally is working just fine. Exporting and mounting that image from a
 Linux box, I can't access this export without crashing the server.
 
 I created files foo, bar and directory test on the image, I mounted
 the export to /mnt, yet these commands all fail: stat /mnt/foo, stat
 /mnt/bar, and stat /mnt/test. stat /mnt/. is working though! As soon
 as I issue a readdir, the NFS server panics.
 
 NB: Locally, this is all working just fine! Here's the backtrace:
 
 panic: vput: null vp
 cpuid = 1
 KDB: stack backtrace:
 kdb_backtrace(100,c8983a80,4000,0,c8983a80,...) at kdb_backtrace+0x29
 panic(c089c295,c8c4ba60,9,80,0,...) at panic+0x114
 vput(0,948,0,a50,0,...) at vput+0x21
 nfsrv_readdirplus(c8be6600,c86f4d00,c8983a80,eaf10c98) at
 nfsrv_readdirplus+0xbe8
 nfssvc_nfsd(c8983a80) at nfssvc_nfsd+0x3d9
 nfssvc(c8983a80,eaf10d04) 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 =
 0xbfbfe91c, ebp = 0xbfbfe938 ---
 KDB: enter: panic
 [thread pid 76119 tid 100100 ]
 Stopped at      kdb_enter+0x2b: nop
 db> show allpcpu
 Current CPU: 1
 
 cpuid        = 0
 curthread    = 0xc8327a80: pid 13 "swi4: clock sio"
 curpcb       = 0xe6e9bd90
 fpcurthread  = none
 idlethread   = 0xc8327780: pid 11 "idle: cpu0"
 APIC ID      = 0
 currentldt   = 0x50
 spin locks held:
 
 cpuid        = 1
 curthread    = 0xc8983a80: pid 76119 "nfsd"
 curpcb       = 0xeaf10d90
 fpcurthread  = none
 idlethread   = 0xc8327600: pid 10 "idle: cpu1"
 APIC ID      = 6
 currentldt   = 0x50
 spin locks held:
 
 db> show alllocks
 Process 76119 (nfsd) thread 0xc8983a80 (100100)
 exclusive sleep mutex Giant r = 0 (0xc09707e0) locked @
 /usr/src/sys/nfsserver/nfs_serv.c:3720
 db> show lockedvnods
 Locked vnodes
 db>
 
 Uli
State-Changed-From-To: open->patched 
State-Changed-By: kib 
State-Changed-When: Thu Feb 15 10:01:46 UTC 2007 
State-Changed-Why:  
Patch by tegge' was just committed. 


Responsible-Changed-From-To: freebsd-bugs->kib 
Responsible-Changed-By: kib 
Responsible-Changed-When: Thu Feb 15 10:01:46 UTC 2007 
Responsible-Changed-Why:  
Patch by tegge' was just committed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92785 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/92785: commit references a PR
Date: Thu, 15 Feb 2007 09:53:58 +0000 (UTC)

 kib         2007-02-15 09:53:50 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/kern             vfs_lookup.c 
   Log:
   If both ISDOTDOT and NOCROSSMOUNT are set then lookup() might breaks out
   of the special handling for ".." and perform an ISDOTDOT VOP_LOOKUP()
   for a filesystem root vnode. Handle this case inside lookup().
   
   Submitted by:   tegge
   PR:             92785
   MFC after:      1 week
   
   Revision  Changes    Path
   1.98      +4 -3      src/sys/kern/vfs_lookup.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: kib 
State-Changed-When: Fri Feb 23 12:28:22 UTC 2007 
State-Changed-Why:  
Patch committed to RELENG_6. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92785 
>Unformatted:
