Subject: Re: newlock
To: Garrett D'Amore <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/05/2006 15:40:39
Content-Type: text/plain; charset=us-ascii
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:
> > =20
> >> Wrong. This works fine in Solaris. The spin mutex doesn't
> >> automatically release the spl -- instead it releases a _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 assumed it
> this to be this way, but reading the Solaris code, it looks like I 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. ;-)
> > OTOH the last solaris drivers I wrote were for 2.5 or 2.6.
> > I also remember it being an absolute pain that you couldn't mask interr=
> > unless yoiu were in the driver that attached t hISR.
> > =20
> Masking interrupts doesn't work on very high end SMP hardware. You're
> still trying to design for systems with less than 8 CPUs.
> The only reason you want to block an interrupt is to keep an ISR from
> clobbering some shared state. So you have a mutex that has the iblock
> cookie set, which blocks the interrupt for you. You can acquire these
> mutexes anywhere (except a higher priority ISR than what you declared at
> mutex creation time!)
I think that's what we've been talking about when we say, "blocking=20
interrupts." You're right that we only mask on one CPU; we keep the ISR=20
from running on our head. If it's on a different head, it has to wait for=
us before starting.
> The system takes care of ensuring that the ISR can't run during this time.
> "Masking interrupts" is the old BSD uniprocessor way of thinking.=20
> Solaris is better. Trust me.
I think we are all on the same page here.
What I am interested in is if there is any provision in the solaris model=
for the lock handoff that ad mentioned. Something where we have two=20
mutexes with "iblock cookies" to quote the above. We start with mutex a=20
locked, but then need to hand off to mutex b. How does Solaris do this?
These scenarios come up in cases where one protocol masks for another.=20
Like ppp or slip, where the data come in on a serial port (spltty() in our=
parlance) but get processed by the networking stack (splnet()). And stuff=
from the networking stack gets processed by serial hardware (going=20
splnet() to spltty()).
Another would be an iSCSI initiator where splbio() and splnet() get
mingled. And heven help someone trying to do iSCSI over ppp. :-)
Other examples would be (could be) where vnd on NFS mingles splbio() and=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----