--DqhR8hV3EnoxUkKN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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...
>=20
> It wouldn't be "documented", because that would be an internal
> implementation detail.
>=20
> 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. :-(
>=20
> 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=
upts
> > unless yoiu were in the driver that attached t hISR.
> >  =20
>=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.
>=20
> 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=
=20
us before starting.

> The system takes care of ensuring that the ISR can't run during this time.
>=20
> "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=
=20
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=
=20
parlance) but get processed by the networking stack (splnet()). And stuff=
=20
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
splnet().

Take care,

Bill

--DqhR8hV3EnoxUkKN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE/fznWz+3JHUci9cRAn/mAJ9/1yYutqTHpcNvxEsQiExi0NbxyQCgloKJ
6evCqhH3Ctm5BJFIetPYDMg=
=NJxI
-----END PGP SIGNATURE-----

--DqhR8hV3EnoxUkKN--