Date: Fri, 12 May 1995 19:21:12 +0300 From: Heikki Suonsivu <hsu@cs.hut.fi> To: freebsd-bugs@freefall.cdrom.com Subject: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Message-ID: <199505121621.TAA03878@shadows.cs.hut.fi> In-Reply-To: Tatu Ylonen's message of 12 May 1995 02:52:01 %2B0300
next in thread | raw e-mail | index | archive | help
>Description:
Spl functions (splbio, splclock, splhigh, splimp, splnet,
splsoftclock, splsofttty, splstatclock, spltty, spl0, splx)
are defined in /usr/src/sys/i386/include/spl.h as inline
functions that modify the ordinary variable cpl (extern
unsigned cpl in the same header).
...
>How-To-Repeat:
The real effects of this problem are not predictable or
deterministic. They may depend on compiler version or
optimization levels. General unreliability, mysterious
problems, and random panics are all likely. I started to
At least two of bugs reported by me were just like this
s = splsomething();
if (foo) {
... something, which does verifyably not modify foo ...
if (foo->bar) /* foo is NULL or garbage here, generating kernel
page fault. */
}
splx(s);
ie. variable getting modified while it is assumed to keep its value. I
think one of these reports was the FreeBSD 1.1.5.1 "print nfs server foo is
alive again through NULL pointer", other was something under 2.*-current,
can't remember which one (there are probably several open ones for me in
GNATS, with stack traces and later ones with some kgdb wanderarounds).
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505121621.TAA03878>