From owner-freebsd-bugs@FreeBSD.ORG Sat Mar 6 02:32:10 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B283316A4CE; Sat, 6 Mar 2004 02:32:10 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 006C143D39; Sat, 6 Mar 2004 02:32:08 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i26AW6Ue004679; Sat, 6 Mar 2004 21:32:06 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i26AW4Gg011034; Sat, 6 Mar 2004 21:32:05 +1100 Date: Sat, 6 Mar 2004 21:32:04 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Lukas Ertl In-Reply-To: <20040306094559.F614@korben.in.tern> Message-ID: <20040306205848.A8077@gamplex.bde.org> References: <200403051548.i25Fmmsa073994@freefall.freebsd.org> <20040306094559.F614@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: pjd@freebsd.org cc: Kris Kennaway Subject: Re: bin/62536: df gives insane numbers when using root-reserved space X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 10:32:10 -0000 On Sat, 6 Mar 2004, Lukas Ertl wrote: > On Sat, 6 Mar 2004, Kris Kennaway wrote: > > > On Fri, Mar 05, 2004 at 07:48:48AM -0800, Lukas Ertl wrote: > > > Synopsis: df gives insane numbers when using root-reserved space > > > .. > > > Responsible-Changed-Why: > > > I probably have a fix for this. > > > > pjd has a patch for this as well..I haven't yet tested it. I discussed this bug with Ian Dowse. As pointed out in my review of the statfs changes, using unsigned types just asks for bugs like this. What chance has the average consumer of statfs avoiding these bugs when its primary consumer (df) gets almost related to the larger sizes and signed types wrong despite being adjusted for the statfs changes? > Index: bin/df/df.c > =================================================================== > RCS file: /home/ncvs/src/bin/df/df.c,v > retrieving revision 1.55 > diff -u -r1.55 df.c > --- bin/df/df.c 5 Mar 2004 08:10:16 -0000 1.55 > +++ bin/df/df.c 5 Mar 2004 15:51:00 -0000 > @@ -400,7 +400,8 @@ > */ > #define fsbtoblk(num, fsbs, bs) \ > (((fsbs) != 0 && (fsbs) < (bs)) ? \ > - (num) / ((bs) / (fsbs)) : (num) * ((fsbs) / (bs))) > + (num) / (int64_t)((bs) / (fsbs)) : \ > + (num) * (int64_t)((fsbs) / (bs))) > > /* I use this with intmax_t instead of int64_t. Such casts are bogus, however, Block sizes are now (bogusly) unsigned, and sometimes 64 bits too. Casts like the above only work if the the original types really are bogus. If all the bits of uint64_t were actually needed to hold block sizes, then the casts would just truncate the values. The truncation is done blindly. Also, the point of the two cases in the above expression was to optimize to avoid 64-bit arithmetic. Now 64-bit arithmetic is unavoidable (the compiler can't even optimize the division of block sizes since block sizes are bogusly 640-bit), and the optimization is a pessimization. Now we can just multiply the number of blocks by the block size provided we don't do it blindly. The result is sure to fit in an off_t unless one of the operands is invalid, and an off_t is sure to fit in an intmax_t if not in an int64_t. Then the above macro is just: #define fsbtoblk(num, fsbs, bs) ((intmax_t)(num) * (fsbs) / (bs)) modulo sanity checks and sign extension bugs. Bruce