Date: Thu, 3 Mar 2011 16:03:09 -0600 From: Brandon Gooch <jamesbrandongooch@gmail.com> To: Matthew Fleming <mdf356@gmail.com> Cc: hackers@freebsd.org, David Wolfskill <david@catwhisker.org> Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned Message-ID: <AANLkTin3VJ11yh92ds=_Y=164WND7AvyT9yn48rR88Su@mail.gmail.com> In-Reply-To: <AANLkTi=1-AOF6jFQjzRSQ3oPGFi5mdKUhDOD0UW5gtw=@mail.gmail.com> References: <20110303174948.GF1471@albert.catwhisker.org> <AANLkTinNQJmVCW3guKzOxbco-C5NDeUuXBnUm1-MRNvA@mail.gmail.com> <AANLkTi=1-AOF6jFQjzRSQ3oPGFi5mdKUhDOD0UW5gtw=@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming <mdf356@gmail.com> wrote: > On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch > <jamesbrandongooch@gmail.com> wrote: >> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill <david@catwhisker.org> = wrote: >>> I'm using a little shell script to capture selected sysctl OID >>> values periodically, in an attempt to get a better idea how the >>> resources of a system are being used during a long-running (usually >>> measured in hours), mission-critical workload. >>> >>> In the process of testing this, I've seen some of the VFS sysctl >>> OIDs (in particular) report negative values ... when the description >>> looks to me as if the OID in question is intended to be a monotonically >>> increasing counter. >>> >>> For example: >>> >>>> sysctl -d vfs.getnewbufcalls >>> vfs.getnewbufcalls: Number of calls to getnewbuf >>>> sysctl vfs.getnewbufcalls >>> vfs.getnewbufcalls: -348909432 >>> >>> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >>> appears to be: >>> >>> ... >>> static int getnewbufcalls; >>> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls,= 0, >>> =A0 "Number of calls to getnewbuf"); >>> ... >>> >>> Many of the other OIDs defined nearby are also SYSCTL_INT (or >>> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >>> variables are defined as static int (or static long) vs. static u_int >>> (or static u_long). >>> >>> Is this both correct and reasonable? =A0If so, how should I interpret s= uch >>> negative values? >>> >>> [GSoC project, anyone?] >>> >>> Thanks! >>> >>> Peace, >>> david >> >> The following initiative may factor heavily into any decision to >> change sysctl declarations at this point: >> >> http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Ty= pe-Safety > > The intent of the type-safety is to make sure that the types assumed > for the kernel's sysctl handler match the type of the variable. =A0This > project won't fix issues where a signed type is being used and the > value wraps (at least, I presume that's what happened in this case?) > > Thanks, > matthew Yes, it's wrapping. I wonder, would an audit of the SYCTL_* types be of general use to FreeBSD? I haven't ran into these issues myself, but I can see where this could become more of a problem with the OS in general as larger, heavier loads are placed on general-purpose type systems; where FreeBSD has been used in a product, I assume that the companies engineers, such as those at Isilon, have applied local patches where necessary. Y'know, I think this could be a good GSoC project after all... -Brandon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin3VJ11yh92ds=_Y=164WND7AvyT9yn48rR88Su>