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?)
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
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.
I don't know whether it cause some problem, for example, if some
softirq need to make a flag in process control block.
Another problem is that softirq handling should have a lower prioirty
than hard irq, right?
Thanks for your attention and help.
Regards
Zefang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
