Subject: Re: newlock
To: Bill Studenmund <>
From: Lars Heidieker <>
List: tech-kern
Date: 09/06/2006 11:20:00
Hash: SHA1

On 6 Sep 2006, at 00:40, Bill Studenmund wrote:

> On Mon, Sep 04, 2006 at 01:35:02PM -0700, Garrett D'Amore wrote:
>> David Laight wrote:
>>> On Sun, Sep 03, 2006 at 07:31:55PM -0700, Garrett D'Amore wrote:
>>>> Wrong.  This works fine in Solaris.  The spin mutex doesn't
>>>> automatically release the spl -- instead it releases a =20
>>>> _reference_ on
>>>> the spl.  The spl is only dropped when the reference reaches zero.
>>> I've never seen that behaviour documented for Solaris...
>> It wouldn't be "documented", because that would be an internal
>> implementation detail.
>> I'm now looking the code, and I'm not so sure.  I had always =20
>> assumed it
>> this to be this way, but reading the Solaris code, it looks like I =20=

>> could
>> be wrong here.  If that's true, then there are a lot of buggy Solaris
>> drivers out there, including one or two that I've written. :-(
>> I'm going to investigate this further.
> Please do. This issue is very interesting to me. ;-)

The order of exiting from the mutexes is important as a spin mutex =20
(Solaris) changes the
ipl level depending on what it is and what the mutex wants but it =20
only increases the protection level
and saves the old level

lock_set_spl is the routine doing this. It is called from =20

The SPARC Version is in:

and if i read the intel version right they don't have real levels in =20
the 32bit version but in the 64bit version
so the problem with the unlock order Garrett describes might not =20
manifest in the 32bit version

Lars Heidieker

- ---

Mystische Erkl=E4rungen.
Die mystischen Erkl=E4rungen gelten f=FCr tief;
die Wahrheit ist, dass sie noch nicht einmal oberfl=E4chlich sind.
      -- Friedrich Nietzsche

Version: GnuPG v1.4.3 (Darwin)