Bug 17405

Summary: one more fstat patch
Product: Base System Reporter: peter.edwards <peter.edwards>
Component: binAssignee: dwmalone
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description peter.edwards 2000-03-16 13:30:00 UTC 
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  .
Comment 1 Bruce Evans 2000-03-16 16:31:46 UTC 
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
Comment 2 Peter Edwards 2000-03-22 11:23:59 UTC 
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 ----
Comment 3 Bruce Evans 2000-03-22 12:40:23 UTC 
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
Comment 4 Peter Edwards 2001-08-02 11:56:20 UTC 
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.
Comment 5 dwmalone freebsd_committer freebsd_triage 2001-08-02 13:37:39 UTC 
Responsible Changed
From-To: freebsd-bugs->dwmalone

I'll try to have a look at this.
Comment 6 dwmalone freebsd_committer freebsd_triage 2001-11-21 10:49:48 UTC 
State Changed
From-To: open->closed

Fix committed to -current and -stable. Thanks!