« Return to Thread: Interrupts as threads
Re: Interrupts as threads
by Bill Stouder-Studenmund
::
Rate this Message:
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:
>
> > On Fri, Dec 01, 2006 at 11:31:19PM +0000, Andrew Doran wrote:
> > >
> > > o There is no easy solution to the lock order problem with the kernel_lock
> > > when using spin locks.
> >
> > 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...
>
> 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
painful (when they hand things off to the main kernel), but we can do it.
Take care,
Bill
> On Sat, Dec 02, 2006 at 10:25:42AM +0000, David Laight wrote:
>
> > On Fri, Dec 01, 2006 at 11:31:19PM +0000, Andrew Doran wrote:
> > >
> > > o There is no easy solution to the lock order problem with the kernel_lock
> > > when using spin locks.
> >
> > 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...
>
> 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 :-).
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
painful (when they hand things off to the main kernel), but we can do it.
Take care,
Bill
attachment0 (193 bytes) « Return to Thread: Interrupts as threads
| Free embeddable forum powered by Nabble | Forum Help |
