From owner-freebsd-bugs@FreeBSD.ORG Mon Jun 27 13:40:24 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4C0116A427 for ; Mon, 27 Jun 2005 13:40:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B40F43D64 for ; Mon, 27 Jun 2005 13:40:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5RDeOuD067317 for ; Mon, 27 Jun 2005 13:40:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5RDeOmX067316; Mon, 27 Jun 2005 13:40:24 GMT (envelope-from gnats) Date: Mon, 27 Jun 2005 13:40:24 GMT Message-Id: <200506271340.j5RDeOmX067316@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/82682: "Accounting resumed" while disk fills up X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2005 13:40:25 -0000 The following reply was made to PR kern/82682; it has been noted by GNATS. From: Bruce Evans To: Wietse Venema Cc: freebsd-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/82682: "Accounting resumed" while disk fills up Date: Mon, 27 Jun 2005 23:39:52 +1000 (EST) On Sun, 26 Jun 2005, Wietse Venema wrote: >> Description: > When the disk fills up, the kernel as expected disables process accounting, but it RESUMES process accounting while the disk fills up further. > > Perhaps the code gets confused when the free space becomes negative (see repeat-by example below). But that is pure speculation. > > I have been using FreeBSD for 10+ years and routinely use dd of /dev/zero to wipe the free space as root. I did not notice this accounting anomaly when I was still using FreeBSD 4. This is one one the many possible and actual sign extension/overflow bugs caused by the poorly chosen types in the 64-bit statfs. From kern_acct.c: %%% if (sb.f_bavail > acctresume * sb.f_blocks / 100) { acctp = savacctp; acctcred = savacctcred; acctflags = savacctflags; savacctp = NULLVP; savacctcred = NOCRED; log(LOG_NOTICE, "Accounting resumed\n"); } %%% In RELENG_4, everything in struct statfs has a non-foot-shooting type (plain long), but in -current after 2003/12/11 the types don't mesh properly; most types are 64 bits; f_bavail is still signed, as it needs to be to represent negative free space, but most of the other types are unsigned, as they need to be to cause sign extension bugs. In the above, `acctresume * sb.f_blocks / 100' has type uint64_t and is not very large, but sb.f_bavail has type int64_t and is not very large in absolute value, so as soon as sb.f_bavail becomes negative it is converted to a huge uint64_t as part of the comparison and the comparison always succeeds. Another bug in the above is that `acctresume * sb.f_blocks' overflows if sb.f_blocks exceeds 1/4 of the maximum for the data type. This overflow is hard to reach since (2^64)/4-1 blocks should be enough for anyone, and even overflow at (2^31)/4 blocks in RELENG_4 is hard to reach due to other limits (mainly the limit of 2^31-1 512-blocks). Bruce