linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070103104305.GA3100@atjola.homenet>
Date:	Wed, 3 Jan 2007 11:43:05 +0100
From:	Björn Steinbrink <B.Steinbrink@....de>
To:	Zefang.Wang@...ia.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Any problem if softirq are done in a interrupt context (IRQ stack)?

[Re-added lkml to the CC list, please don't drop anything from CC]

On 2007.01.03 17:39:48 +0800, Zefang.Wang@...ia.com wrote:
> Hi!
> 
> Thanks very much for your clear explanation !
> 
> I have another question about irq_exit(), hope you can help me.
> 
> void irq_exit(void)
> {
> 	account_system_vtime(current);          
> 	trace_hardirq_exit();
> 	sub_preempt_count(IRQ_EXIT_OFFSET);   
>            ====================================================================
> 		Here, IRQ_EXIT_OFFSET is defined as (HARDIRQ_OFFSET-1),
> 		so the purpose seems that it try to avoid the current process
> 		from being switched-out druing do_softirq()?
> 		And,  if the preempt_count is not zero,  then softirq for 
> 		timer interrupt can set  _TIF_NEED_RESCHED flag to current
> 		process?
> 		What happened if the above sentence is changed to
> 		sub_preept_count(HARDIRQ_OFFSET)?
> 
> 	if (!in_interrupt() && local_softirq_pending())
> 		invoke_softirq();
> 	preempt_enable_no_resched();
>              ==============================================
> 	 The remaining 1 is decremented here.
> }

I can't really help you with that one. I'd assume that you need to make
sure that the current process context is kept while the softirq is
running. Could be, that otherwise the process gets preempted and the
stored process context would be assigned to the new process or
something like that, but I'm just guessing wildly here.
Note that IRQ_EXIT_OFFSET is defined as HARDIRQ_OFFSET if preemption is
disabled, so that's probably key here, I just don't know what kind of
havoc preempting would cause here ;)

Björn
-
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/