Re: kern/41154: possible races in NFS server code ?

[Andrew Doran <ad%netbsd.org@localhost>]

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

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/41154: possible races in NFS server code ?
Date: Wed, 8 Apr 2009 20:17:08 +0000

 On Wed, Apr 08, 2009 at 08:10:04PM +0000, Andrew Doran wrote:
 
 > The following reply was made to PR kern/41154; it has been noted by GNATS.
 > 
 > From: Andrew Doran <ad%netbsd.org@localhost>
 > To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > Cc: gnats-bugs%netbsd.org@localhost
 > Subject: Re: kern/41154: possible races in NFS server code ?
 > Date: Wed, 8 Apr 2009 20:08:42 +0000
 > 
 >  On Wed, Apr 08, 2009 at 09:23:33PM +0200, Manuel Bouyer wrote:
 >  
 >  > @@ -889,9 +887,12 @@
 >  >                   closef(fp);
 >  
 >  Calling closef() while holding nfsd_lock makes me uncomfortable. In this
 >  case we know it is a socket, so I think it should be OK, but there could be
 >  unexpected deadlocks. Better to free it afterwards I think..
 >  
 
 Actually it looks like there *is* a problem with doing this.
 
 socket upcall -> nfsrv_soupcall -> nfsrv_wakenfsd -> mutex_enter(&nfsd_lock)
 
 So this defines the current lock order as socket::so_lock -> nfsd_lock.