From nobody@FreeBSD.org  Thu Mar 16 05:23:50 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 7AE8337BA4F
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 16 Mar 2000 05:23:50 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id FAA02112;
	Thu, 16 Mar 2000 05:23:50 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Message-Id: <200003161323.FAA02112@freefall.freebsd.org>
Date: Thu, 16 Mar 2000 05:23:50 -0800 (PST)
From: peter.edwards@ireland.com
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: one more fstat patch
X-Send-Pr-Version: www-1.0

>Number:         17405
>Category:       bin
>Synopsis:       one more fstat patch
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dwmalone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 16 05:30:00 PST 2000
>Closed-Date:    Wed Nov 21 02:49:48 PST 2001
>Last-Modified:  Wed Nov 21 02:50:05 PST 2001
>Originator:     Peter Edwards
>Release:        rapidly ageing -current
>Organization:
>Environment:
FreeBSD rocklobster 4.0-CURRENT FreeBSD 4.0-CURRENT #3: Fri Jan 21 09:42:06 GMT 2000     petere@rocklobster:/usr/src/sys/compile/PME2  i386

>Description:
fstat "file", where file is on an NFS volume, is still broken.
The problem is that the fsid is made up of a type and a dev_t.
the nfs_filestat() doesn't drop the type (to produce a udev_t) by &ing
with 0xffff. All the other filesystem types do this already.


>How-To-Repeat:
$ cd /net/rover/export/home
$ fstat .
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
$ cd /usr/src/usr.bin/fstat
$ patch fstat.c < patch
$ make all install
$ cd -
$ fstat .
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
root     fstat       3232   wd /a/rover/host/export/home      2 drwxr-xr-x     512  r  .
root     bash        3045   wd /a/rover/host/export/home      2 drwxr-xr-x     512  r  .




>Fix:
*** fstat.c     Thu Mar 16 02:02:33 2000
--- fstat.pme.c Thu Mar 16 13:05:09 2000
***************
*** 508,514 ****
                    (void *)VTONFS(vp), Pid);
                return 0;
        }
!       fsp->fsid = nfsnode.n_vattr.va_fsid;
        fsp->fileid = nfsnode.n_vattr.va_fileid;
        fsp->size = nfsnode.n_size;
        fsp->rdev = nfsnode.n_vattr.va_rdev;
--- 508,514 ----
                    (void *)VTONFS(vp), Pid);
                return 0;
        }
!       fsp->fsid = nfsnode.n_vattr.va_fsid & 0xffff;
        fsp->fileid = nfsnode.n_vattr.va_fileid;
        fsp->size = nfsnode.n_size;
        fsp->rdev = nfsnode.n_vattr.va_rdev;


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: peter.edwards@ireland.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/17405: one more fstat patch
Date: Fri, 17 Mar 2000 03:31:46 +1100 (EST)

 On Thu, 16 Mar 2000 peter.edwards@ireland.com wrote:
 
 > >Description:
 > fstat "file", where file is on an NFS volume, is still broken.
 > The problem is that the fsid is made up of a type and a dev_t.
 > the nfs_filestat() doesn't drop the type (to produce a udev_t) by &ing
 > with 0xffff. All the other filesystem types do this already.
 
 This is backwards.  &ing with 0xffff is a bug.  The bug is fixed for ufs
 in PR 16320.
 
 Bruce
 
 

From: Peter Edwards <peter.edwards@openet-telecom.com>
To: bde@zeta.org.au
Cc: freebsd-gnats-submit@FreeBSD.ORG, peter.edwards@ireland.com
Subject: Re: Re: bin/17405: one more fstat patch
Date: Wed, 22 Mar 2000 11:23:59 +0000

 Hi,
 With getfname &ing 0xffff, and nfs_filestat() not doing it, you'll
 never find the filesystem for an NFS inode. I guess I picked adding
 one 0xffff rather than removing the rest, 'cause it seemed more likely
 the single omission was in error rather than the two or three uses 
 of 0xffff.
 
 I suppose my bug is that the 0xffff is being applied inconsistently,
 while the quoted PR's bug is that the 0xffff is incorrect :)
 Is the 0xffff is some historical artifact, then?
 
 If someone removes the 0xffff's, a la bin/16320, be sure to catch the
 new ones in msdosfs.c and cd9660.c
 
 Cheers,
 Peter.
 
 ---- Begin Original Message ----
 From: Bruce Evans <bde@zeta.org.au>
 Sent: Fri, 17 Mar 2000 03:31:46 +1100 (EST)
 To: peter.edwards@ireland.com
 CC: freebsd-gnats-submit@FreeBSD.ORG
 Subject: Re: bin/17405: one more fstat patch
 
 On Thu, 16 Mar 2000 peter.edwards@ireland.com wrote:
 
 > >Description:
 > fstat "file", where file is on an NFS volume, is still broken.
 > The problem is that the fsid is made up of a type and a dev_t.
 > the nfs_filestat() doesn't drop the type (to produce a udev_t) by &ing
 > with 0xffff. All the other filesystem types do this already.
 
 This is backwards.  &ing with 0xffff is a bug.  The bug is fixed for ufs
 in PR 16320.
 
 Bruce
 
 
 ---- End Original Message ----
 

From: Bruce Evans <bde@zeta.org.au>
To: Peter Edwards <peter.edwards@openet-telecom.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG, peter.edwards@ireland.com
Subject: Re: Re: bin/17405: one more fstat patch
Date: Wed, 22 Mar 2000 23:40:23 +1100 (EST)

 On Wed, 22 Mar 2000, Peter Edwards wrote:
 
 > Hi,
 > With getfname &ing 0xffff, and nfs_filestat() not doing it, you'll
 > never find the filesystem for an NFS inode. I guess I picked adding
 > one 0xffff rather than removing the rest, 'cause it seemed more likely
 > the single omission was in error rather than the two or three uses 
 > of 0xffff.
 
 Well, until about 6 months ago, the nfs fsid was
 makedev(128 + mtype, xxxfs_mntid) (see kern_conf.c:getnewfsid()), so
 nfs fsids were <= 0xffff in the usual case where there have been <= 256
 mount(2) calls for non-disk filesystems.
 
 > I suppose my bug is that the 0xffff is being applied inconsistently,
 > while the quoted PR's bug is that the 0xffff is incorrect :)
 > Is the 0xffff is some historical artifact, then?
 
 I think it is just a wrong fix for bogus sign extension caused by dev_t
 being (signed) short.
 
 Bruce
 
 

From: Peter Edwards <peter.edwards@openet-telecom.com>
To: freebsd-gnats-submit@FreeBSD.org, peter.edwards@ireland.com
Cc: bde@zeta.org.au
Subject: Re: bin/17405: one more fstat patch
Date: Thu, 02 Aug 2001 11:56:20 +0100

 Can someone drop all the "& 0xffff"'s from the files in
 src/usr.bin/fstat? It fixes this bug, and I've been running with it for
 the last year, locally.
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Thu Aug 2 05:37:39 PDT 2001 
Responsible-Changed-Why:  
I'll try to have a look at this. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17405 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Wed Nov 21 02:49:48 PST 2001 
State-Changed-Why:  
Fix committed to -current and -stable. Thanks! 

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