From owner-freebsd-bugs  Fri Apr 18 09:00:05 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA13532
          for bugs-outgoing; Fri, 18 Apr 1997 09:00:05 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA13507;
          Fri, 18 Apr 1997 09:00:02 -0700 (PDT)
Date: Fri, 18 Apr 1997 09:00:02 -0700 (PDT)
Message-Id: <199704181600.JAA13507@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Subject: Re: kern/3304: NFS V2 readdir hangs
Reply-To: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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: Fri, 18 Apr 1997 11:49:35 -0400 (EDT)

 More information...
 
 
 Here's the scenario I've now determined (via more printf()s in the
 kernel):
 
    1) nfs_request() is called from readdirrpc().
 
    2) nfs_request malloc's a nfsreq block, which is used
       by rcvlock()... the lock is granted; we go down to
       soreceive() and wind up tsleeping in sbwait().
 
    3) At this point, a vnode lookup() operation is called.
       The lookup() isn't satisfied from the cache; so 
       we call nfs_request() to get the information.
 
    4) This nfs_request() malloc's a different nfsreq block.
       The "lock" is granted since rcvlock() works on addresses
       from the nfsreq block; these are different addresses, the
       lock is granted.  We wind down to soreceive()
       again.
 
    5) udp_intr() is called because a UDP packet arrived...
       this is, presumably, the packet we're expecting from 2).
       *however* the last request we received was from 4).
       That is the nfsreq this packet winds up being associated
       with; but - it is totally wrong.  
 
  So; we're left with the lookup() failing with a ENONENT (#2),
 and the nfs_request from #2 hanging; never being woken up.
 
   I think that pretty well describes my findings.
 
   Perhaps the rcvlock() needs to change to lock on something other
 than the nfsreq block... does anyone have any suggestions?
 
   	- Dave Rivers -