Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03

[Ingo Molnar]

* Mark Gross <mgross@xxxxxxxxxxxxxxx> wrote:

> On Monday 14 February 2005 13:24, Steven Rostedt wrote:
> > On Mon, 2005-02-14 at 12:40 -0800, Mark Gross wrote:
> > > I'm working on a tweak to the preepmtive soft IRQ implementation using
> > > work queues and I'm having problems with a BUG assert when trying to
> > > queue_work.
> > >
> > > Souldn't I be able to call queue_work form ISR context?
> >
> > Yes, but not with interrupts disabled.
> 
> Hmm.  It seems to me that one should be able to call queue_work from
> wherever you can call raise_softirq.  This constraint adds a bit of
> asymetry in the deffered processing API's

one solution is to use the local_irq_*_nort() API variants - but it all
depends on why you had to disable interrupts.

Almost always irq-disabling done in conjunction with spinlocks, and the
spin_lock_irq*() variants do not disable interrupts on PREEMPT_RT. I
kept the assymetry of the local_irq*() APIs because in most cases they
are used directly interrupts need to be disabled.

it is also the more conservative approach, since we'll get messages like
the ones you got when it's unsafe to do it - while if local_irq_*() APIs
didnt disable interrupts we'd never know about the cases when they
_must_ be disabled.)

but yes, there's some API assymetry - which mostly comes from the fact
alone that 99.999% of the kernel is now preemptible. There's just so
much we can do to pretend that this is good'old Linux kernel semantics
:-)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/