A question about the softirq implementation in DDE Linux26

Christian Helmuth christian.helmuth at genode-labs.com
Mon Mar 1 10:58:32 CET 2010


On Mon, Mar 01, 2010 at 10:45:44AM +0800, Da Zheng wrote:
> I don't think it can work on one CPU either. The problem is caused when the
> softirq thread is preempted by the interrupt thread. When you set the interrupt
> thread a higher priority, it's more likely the softirq thread gets preempted.
> softirq queue manipulation must be atomic.

Right, that's what I wrote.

> > I think this addresses our issue in a way: Prevent handling of the
> > just registered softirq until the interrupt handler returns.
> What if the softirq thread is running when an interrupt comes? Since we cannot
> disable the hard irq, it is very likely to happen.
> > Afterwards, the registered softirq can be handled from the standard
> > softirq thread as long as the queue manipulation is atomic. The issue
> > is now near the top of our agenda for DDE.
> If you only consider about handling the softirq queue, I think it's easy, simply
> using a lock to protect it explicitly, but it cannot solve the problem
> completely. There should be many race conditions in other places. I implement
> raw_local_irq_disable() and raw_local_irq_enable() with a lock, but there is
> still a serious problem. Because of spin_lock_irqsave, there can be dead locks.
> One example is in pcnet32_watchdog() and pcnet32_interrupt(). So I think we can
> just let spin_lock_irqsave() become spin_lock(). After all, the interrupt
> handling doesn't run in the real interrupt context any more, so I think there is
> no reason to do spin_lock_irqsave() or spin_lock_irq().

Sounds like my idea behind the current scheme. Thanks for your input
on this.

Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the l4-hackers mailing list