lkml.org 
[lkml]   [2007]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2007-01-03 10:25    [W:0.062 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site