Hello,
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.
Regards