Path: utzoo!attcan!uunet!munnari!murtoa.cs.mu.oz.au!cs.mu.oz.au!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: Surprising fact about STREAMS service modules
Summary: "fixing" the splN() routines isn't as easy as it might seem
Message-ID: <1138@murtoa.cs.mu.oz.au>
Date: 27 Dec 88 08:51:09 GMT
References: <4385@hcr.UUCP> <313@taniwha.UUCP> <11047@ulysses.homer.nj.att.com> <15167@mimsy.UUCP>
Sender: news@cs.mu.oz.au
Lines: 46

In article <11047@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com
(Steven M. Bellovin) writes:
>A persistent bug source, in many versions on the UNIX system, is that
>splN() calls, other than splx(), unconditionally set the interrupt
>level to the indicated value, rather than *raising* it to that value.

In article <15167@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) describes
a use for deliberately lowering the IPL, then continues:
> A more flexible approach might be to define `raisepl' inlines (perhaps
> `rpl'?), to be used in appropriate places.  Or simply use the current
> system and declare that all kernel hackers must keep their priorities
> straight :-) .

Chris's apparently tounge-in-cheek remark/pun is probably really the
way that it has to be.  Preventing splN() from lowering the IPL only
solves half of the problem.

Eg: if you're in a disc driver intr routine at IPL 6, and you want to
protect a call of some single use routine, and you call spl5()
(incorrectly lowering the IPL, and perhaps permitting another level 6
interrupt, maybe even from the same controller, and generally weraking
havoc), having spl5() notice that you were at IPL 6, and thus leaving
you at level 6 will help a little.

But what of some other routine that had (correctly) raised its IPL to
level 5, and called the same routine, and was half way through when
your controller interrupted at level 6 .. the interrupt routine's call
of the that single-use routine just scrambled the system, at whatever IPL
that call actually runs.

Using interrupt lockout to implement monitors (the way that single
processor unix always has) simply requires care and planning by the
programmers, there's no way to allow sloppy programming and keep this
scheme working.

With the move to multi-processor kernels, all of these problems should
vanish, there should be no reason for any uses of splN() routines at
all, something much more powerful is required.

If you want to protect yourself against sloppy programming, the proper
technique is to make the splN() routines panic if there's an attempt to
lower priority, and perhaps add some loweripl() routines for the odd
cases where lowering the IPL is a desired result (to compensate for
broken hardware, or whatever).

kre