Subject: Re: CVS commit: src/sys
To:, der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Christos Zoulas <>
List: tech-security
Date: 06/24/2007 22:13:16
On Jun 24, 10:02pm, (Thor Lancelot Simon) wrote:
-- Subject: Re: CVS commit: src/sys

| On Sun, Jun 24, 2007 at 04:10:18PM -0400, der Mouse wrote:
| > > It seems to me (and in fact I maintain a libc that does this) that
| > > there are a number of system calls whose result can be known to libc
| > > without bothering to talk to the kernel.  The obvious ones are
| > > getpid(), getppid(), and so forth but getgroups() ought to fall into
| > > this category too after the first call, and barring any use of
| > > certain intermediate syscalls.
| > 
| > getppid actually does not qualify, since the parent can die, and the
| > ppid thus change to 1, without libc having a chance to notice.
| Well, this can be handled with an appropriate kevent and some kernel magic
| -- though I would not necessarily advocate that for NetBSD's libc.
| > > This would cause problems for applications that mixed hand-coded
| > > syscalls and libc, but I'm not so sure I care,
| > 
| > Why not?  Do you have reason to think nobody is doing that?  (Not
| > having reason to think anybody is is not the same as having reason to
| > think nobody is.)
| I'm not sure I care because if you do things behind the C runtime's back,
| you're in the realm of implementation-defined behavior and _that_ is your
| own lookout.
| > Furthermore, you don't mention any reason to think that the calls that
| > can be optimized this way are used heavily enough to make it worth the
| > bother - and potential compatability issues - of doing so.  Do you have
| > such a reason?
| Indeed, I do.  This optimization for getpid() alone yields hundreds of
| transactions per second of improvement on the primary benchmark for my
| application, all because of avoided context switches into the kernel and
| back.  It also yields a measurable improvement in system build times since
| the build framework is a fairly heavy getpid() user.  That's valuable enough
| to me to maintain it in my libc at work; whether it is valuable enough to
| NetBSD, I don't know.

It would be nice if someone implemented a commpage for NetBSD and stuffed all
this info there.