Date: Thu, 17 Apr 1997 19:30:04 -0700 (PDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: freebsd-bugs Subject: Re: kern/3304: NFS V2 readdir hangs Message-ID: <199704180230.TAA25674@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/3304; it has been noted by GNATS. From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!lakes.water.net!rivers, ponds!khavrinen.lcs.mit.edu!wollman Cc: ponds!freefall.freebsd.org!freebsd-gnats-submit Subject: Re: kern/3304: NFS V2 readdir hangs Date: Thu, 17 Apr 1997 21:12:42 -0400 (EDT) > Garrett writes: > > <<On Thu, 17 Apr 1997 09:30:02 -0700 (PDT), Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> said: > > > It appears that nfs_receive() calls soreceive() which calls sbwait() > > waiting on a UDP packet to be received.. That's fine. > > > Then, another nfs_request() is issued; calling nfs_receive() which > > winds down to sbwait() as well. > > > Then, the udp packet from the first call is received; we wake up the > > *second* caller and get everything out-of-sync. > > This is perfectly reasonable behavior for soreceive(). NFS is clearly > broken here. NFS needs its own response-demultiplexing layer, it > seems. > > -GAWollman > Well - yes; except in this instance there is a lock protecting the multiple soreceive()s, nfs_rcvlock(). I think the question is why didn't that protection work. [In fact, there's a comment in nfs_socket.c that indicates the rcvlock is used to protect from just this situation.] Apparently, since 2.1.5 runs on the same machine just fine; this used to work and has now been compromised.... [that's just a guess.] - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704180230.TAA25674>