Messages in this thread | | | Date | Wed, 3 Jan 2007 10:22:14 +0100 | From | Björn Steinbrink <> | Subject | Re: Any problem if softirq are done in a interrupt context (IRQ stack)? |
| |
On 2007.01.03 16:23:28 +0800, Zefang.Wang@nokia.com wrote: > Hello all! > > Kernel version : 2.6.18 > Arch : i386 > > With the following conditions, it is possible that softirqs are > executed in a interrupt context rather than process one > 1) CONFIG_4KSTACKS ----> ON > That means the dedicated IRQ stack is used for hardirq handler > > 2) there exist some Hard IRQ which allows interupt enabled when its > handler being executed. > That means a possibility that a HARD IRQ handler is interrupted by > another one. > > 3) CONFIG_LOCKDEP ---> OFF > Instruction sti will be executed by local_irq_enable_in_hardirq() > > > Let's suppose the following situation. > 1) A process is running without local irq nor bottom half disabled. > 2) A hardware interrupt happened. > 3) After saving context in process kernel stack, it switch to irq > stack. > But notice : the preempt_count in irq stack will be zero, because > do_irq does not add HARDIRQ_OFFSET to the preept_count. > (anyone tell me the reason?)
Because irq_ctx_init() initializes the preempt count to HARDIRQ_OFFSET, the value is already correct.
> > if (curctx != irqctx) { > int arg1, arg2, ebx; > > /* build the stack frame on the IRQ stack */ > isp = (u32*) ((char*)irqctx + sizeof(*irqctx)); > irqctx->tinfo.task = curctx->tinfo.task; > irqctx->tinfo.previous_esp = current_stack_pointer; > > /* > * Copy the softirq bits in preempt_count so that the > * softirq checks work in the hardirq context. > */ > irqctx->tinfo.preempt_count = > (irqctx->tinfo.preempt_count & ~SOFTIRQ_MASK) | > (curctx->tinfo.preempt_count & SOFTIRQ_MASK); > > > 4) then __do_irq is called, and handle_irq_event is called. Before > that, local irq is enabled because the interrupt allow it. > 5) during the execution of the hardirq actions, another hardware > (depth 2 interrurpt) interrupt happened. > 6) SAVE context, and then hardirq handler, during the handler, some > softirq is marked
Note that curctx is equal to irqctx in this case, so we stay with the hardirq context and the irq_enter() in do_IRQ() does the right thing. The preempt count is incremented to HARDIRQ_OFFSET+1.
> 7) when depth 2 interrrupt call irq_exit(), surely do_softirq will be > called because in_interrupt return a FALSE. > In this point, the stack is still irq stack.
No, irq_exit() will decrement the preempt count back to HARDIRQ_OFFSET, so in_interrupt() will return true.
And the irq_exit() call for the first irq will actually happen in process context, so a) the hard irq context's preempt count will stay at HARDIRQ_OFFSET and b) the hardirq count in the process context will go back to 0 (it was raised to 1 by the initial irq_enter() call).
HTH Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |