linux-kernel - Any problem if softirq are done in a interrupt context (IRQ stack)?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1E9D602D891FA142A769E9EF164712EC355C3A@beebe101.NOE.Nokia.com>
Date:	Wed, 3 Jan 2007 16:23:28 +0800
From:	<Zefang.Wang@...ia.com>
To:	<linux-kernel@...r.kernel.org>
Cc:	<Zefang.Wang@...ia.com>
Subject: Any problem if softirq are done in a interrupt context (IRQ stack)?

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/