Date: Fri, 10 Nov 1995 12:14:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: lm@slovax.engr.sgi.com, hackers@FreeBSD.org, waa@aurora.cis.upenn.edu, deraadt@theos.com, chuck@maria.wustl.edu Subject: Re: larry: you might want to add this to lmbench (but i'm not sure) Message-ID: <199511101914.MAA04103@phaeton.artisoft.com> In-Reply-To: <Pine.SOL.3.91.951110110255.13530A-100000@morse> from "Ron G. Minnich" at Nov 10, 95 11:15:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> this program does a very simple thing: > 1) open a file > 2) call write with an invalid address, viz: > write(fd, x, 5); > where x is (void *) 0x40000000 > > it does this as many times as you ask. What it's measuring is correlated > to the raw performance of the system's ability to look up a vm region or > segment or object given a virtual address. It is not a pure measure, > since systems that do a lot of work before checking the arguments > (freebsd) will fare worse than systems that just check the arguments up > front for validity (linux). On the other hand, all the system calls that > happen a lot have to do this operation, so you probably want this type of > thing to be fast. I'm sorry for the tone of what follows, but this is a stupid benchmark. On a kernel multithreaded system, and moreso in the case of SMP, prechecking opens a nice window unless you combine it with a reservation mechanism on the order of the mechanism employed by the VFS system in FreeBSD, but applied to memory ranges. Linux does prechecking and they have SMP and kernel multithreading, which leads to some nice races through which you can get system priveledges. This is basically the same race you use to bust security on an NT system, since it does the same type of prechecking without reservation. Clearly, these people do not understand multithreading sufficiently. I'm an advocate of prechecking before doing the operation in BSD, but without concommitant changes for establishing a reservation in the case of a non-failure and some mechanism for giving up the reservation in case of a different failure (the same type of layering problem the VFS currently has with cn_pnbuf), there's no way that prechecking can be considered a win. So in Linux, it's a loss on security, even if it is a win on time. And once the security issues are addressed, the "win" will be more expensive on successful operations. Any benchmark that promotes optimization of failure cases is critically flawed, and anyone who then spends time to get a better score on that benchmark silly in the extreme. You must have explicitly turned off SIGSEGV and SIGBUS in order to perform these tests. One wonders how much of your time is spent in the sigtrampoline code: another case of a failure path requiring optimization to better the score. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511101914.MAA04103>