From serge@jbj.org  Sun Aug 17 15:14:43 1997
Received: from serge.jbj.org (serge.JBJ.ORG [198.178.231.60])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA27639
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 17 Aug 1997 15:14:40 -0700 (PDT)
Received: (from serge@localhost) by serge.jbj.org (8.8.6/8.6.12) id SAA08596; Sun, 17 Aug 1997 18:14:38 -0400 (EDT)
Message-Id: <199708172214.SAA08596@serge.jbj.org>
Date: Sun, 17 Aug 1997 18:14:38 -0400 (EDT)
From: Serge Pashenkov <serge@jbj.org>
Reply-To: serge@jbj.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: NFS over TCP reconnect problem
X-Send-Pr-Version: 3.2

>Number:         4327
>Category:       kern
>Synopsis:       NFS over TCP reconnect problem
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    peter
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 17 15:20:00 PDT 1997
>Closed-Date:    Sat May 12 16:27:01 PDT 2001
>Last-Modified:  Sat May 12 16:28:22 PDT 2001
>Originator:     Serge Pashenkov
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
>Environment:

	2.2-stable circa Aug 15

>Description:

I'm running into funny NFS over TCP problem. Mount works fine and the
filesystem is there for a while, I can access it and all. After a
while the connection goes into CLOSE_WAIT status, which I think is
just normal timeout after period of inactivity, and actually should
reconnect on request, but that's exactlty where the problem is.

nfs_connect() (called from nfs_reconnect()) tries to bind a privileged
port (well, mount_nfs command sets it regardless, even though there is
-P flag), so eventually it gets to in_pcbbind() which checks suser()
in case of privileged port with CURRENT proc credentials. So, if super
user happens to be the one to initiate the request everything is fine,
but if it was non-superuser there is a problem, connection is never
gonna be reistablished.

Situation gets even worse if non-superuser invoked df command. In that
case the filesystem is just hung forever -- vfs struct is locked in
getfsstat(), and then eventually nfs_reconnect() gets called and loops
forever attempting to connect, having vfs struct still locked. There
is no way to neither unmount the file system not even cleanly reboot
the machine, everything hangs on the locked vfs struct.


>How-To-Repeat:

	mount -o -T server:/filesystem /mountpoint

	wait 5 min, or until CLOSE_WAIT status for the nfs
	connection is displaied in systat net display

	df (not being super user).


>Fix:
	
As a workaround I use modified version of mount_nfs with regular port use 
(unless -P is specidied), but I'm lucky that my server does not require
privileged port.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->peter 
Responsible-Changed-By: peter 
Responsible-Changed-When: Wed May 20 00:44:41 PDT 1998 
Responsible-Changed-Why:  
I'll take this one 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Wed Mar 28 11:57:58 PST 2001 
State-Changed-Why:  
Is this still a problem with recent releases? I think Matt Dillon 
fixed an number of NFS over TCP problems some time ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4327 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Sat May 12 16:27:01 PDT 2001 
State-Changed-Why:  

Feedback timeout, and I can't reproduce this on a recent system. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=4327 
>Unformatted:
