Re: Interrupts as threads

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

On Sun, Dec 03, 2006 at 10:36:30PM +0000, Andrew Doran wrote:
> On Sat, Dec 02, 2006 at 10:25:42AM +0000, David Laight wrote:
>=20
> > On Fri, Dec 01, 2006 at 11:31:19PM +0000, Andrew Doran wrote:
> > >=20
> > > o There is no easy solution to the lock order problem with the kernel=
_lock
> > >   when using spin locks.
> >=20
> > My brief peruse at the biglock code did make it clear how it worked when
> > an IRQ came in when the 2nd cpu had the biglock...
>=20
> The problem is that at the moment, acquiring any given spin lock is a
> deadlock waiting to happen unless you are at ~IPL_SCHED or above when
> acquiring it, or are certain that it will only ever be acquired with the
> kernel lock unheld. Ensuring that the kernel lock is always held when you
> acquire the spin lock means that the spin lock is useless :-).

I've been thinking about this, and I think you are not correct. Well. In
the long-term, you are. But I think as a transition step, we may have to
accept it.

All we have to do is define a correct locking hierarcy. It's ok to aquire
a given spin lock if you have the kernel lock. It's ok to aquire said
spinlock w/o the kernel lock. It's just NOT ok to aquire the kernel lock
while holding said lock. Yes, this could make interupt handling routines=20
painful (when they hand things off to the main kernel), but we can do it.

Take care,

Bill

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

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

iD8DBQFFiH5EWz+3JHUci9cRAvyqAJkBe+MFrM3g7QF7lfHzrzJx/kabXQCgi71E
aNFsbOirdodNS240v6Gpn5Q=
=JiVP
-----END PGP SIGNATURE-----

--GID0FwUMdk1T2AWN--