Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 May 2011 16:27:23 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        rmacklem@freebsd.org, kib@freebsd.org, fs@freebsd.org
Subject:   Re: newnfs client and statfs
Message-ID:  <733531363.835298.1304281643548.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <20110502035720.F2645@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
> On Sun, 1 May 2011, Rick Macklem wrote:
> 
> >> UINT64_MAX, etc., are defined in <sys/stdint.h>, which doesn't even
> >> need
> >> to be included explicitly, since it is (bogusly) standard namespace
> >> pollution in <sys/systm.h>. This namespace pollution gives the
> >> bizarre
> >> ...
> 
> > Ok, now I see them (in machine/include/_stdint.h). Appologies for
> > the
> > noise. I grep'd sys/sys and couldn't find anything called
> > (U)INT64_MAX.
> >
> > Now, remembering that sf_abytes is uint64_t per the RFCs, what do
> > people
> > think of either of these?
> >
> >  if (sfp->sf_abytes > INT64_MAX)
> >      sbp->f_bavail = INT64_MAX;
> >  else
> >      sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE;
> 
> You don't need to do anything at runtime, since everything is 64 bits
> and f_bavail is a block count while sf_abytes is a byte count. 1 bit
> is lost to the sign bit in f_bavail, but 9 bits are gained by scaling
> by NFS_FABLKSIZE, leaving 8 bits to spare.
> 
> Calculating the limit at runtime would give INT64_MAX /
> NFS_FABSBLKSIZE,
> or perhaps 1 more than that (to round up instead of down). You might
> still want to use an out-of-band limit like INT64_MAX for technical
> reasons, but that risks more bugs (for example, anything converting
> INT64_MAX / NFS_FABSBLKSIZE + 1 "back" to a byte count would overflow
> and anything converting INT64_MAX "back" to a byte count would
> overflow
> even uint64_t.
> 
> > Or should I try and do the division to see if the large
> > value in sf_abytes will fit in INT64_MAX after the division?
> > Something
> > like:
> 
> Runtime tests have the advantage of continuing to work if someone
> changes
> the types, provided they are robust, but making them robust is too
> hard
> here. Robust test's can't simply use INT64_MAX, since INT64_MAX is
> only
> the max if the type is int64_t...
> 
Ok, I realized the code in the last post was pretty bogus:-) My only
excuse was that I typed it as I was running out the door...

So, I played with it a bit and the attached patch seems to work for
i386. For the fields that are uint64_t in struct statfs, it just
divides/assigns. For the int64_t field that takes the divided value
(f_bavail) I did the division/assignment to a uint64_t tmp and then
assigned that to f_bavail. (Since any value that fits in uint64_t is
a positive value for int64_t after being divided by 2 or more, it will
always be positive.) For the other int64_t one, I just check for "> INT64_MAX"
and set it to INT64_MAX for that case, so it doesn't go negative.

Anyhow, the updated patch is attached and maybe kib@ can test it?

Thanks for the help with this. I realize I got rather confused during
the discussion, rick

[-- Attachment #2 --]
--- fs/nfsclient/nfs_clport.c.sav	2011-04-30 20:16:39.000000000 -0400
+++ fs/nfsclient/nfs_clport.c	2011-05-01 16:11:18.000000000 -0400
@@ -838,20 +838,19 @@ void
 nfscl_loadsbinfo(struct nfsmount *nmp, struct nfsstatfs *sfp, void *statfs)
 {
 	struct statfs *sbp = (struct statfs *)statfs;
-	nfsquad_t tquad;
+	uint64_t tmp;
 
 	if (nmp->nm_flag & (NFSMNT_NFSV3 | NFSMNT_NFSV4)) {
 		sbp->f_bsize = NFS_FABLKSIZE;
-		tquad.qval = sfp->sf_tbytes;
-		sbp->f_blocks = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
-		tquad.qval = sfp->sf_fbytes;
-		sbp->f_bfree = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
-		tquad.qval = sfp->sf_abytes;
-		sbp->f_bavail = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
-		tquad.qval = sfp->sf_tfiles;
-		sbp->f_files = (tquad.lval[0] & 0x7fffffff);
-		tquad.qval = sfp->sf_ffiles;
-		sbp->f_ffree = (tquad.lval[0] & 0x7fffffff);
+		sbp->f_blocks = sfp->sf_tbytes / NFS_FABLKSIZE;
+		sbp->f_bfree = sfp->sf_fbytes / NFS_FABLKSIZE;
+		tmp = sfp->sf_abytes / NFS_FABLKSIZE;
+		sbp->f_bavail = tmp;
+		sbp->f_files = sfp->sf_tfiles;
+		if (sfp->sf_ffiles > INT64_MAX)
+			sbp->f_ffree = INT64_MAX;
+		else
+			sbp->f_ffree = sfp->sf_ffiles;
 	} else if ((nmp->nm_flag & NFSMNT_NFSV4) == 0) {
 		sbp->f_bsize = (int32_t)sfp->sf_bsize;
 		sbp->f_blocks = (int32_t)sfp->sf_blocks;

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?733531363.835298.1304281643548.JavaMail.root>