linux-kernel - Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Jun 2007 15:43:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@...radead.org>,
	john stultz <johnstul@...ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	"David S. Miller" <davem@...emloft.net>, matthew.wilcox@...com
Subject: Re: [RFC PATCH 0/6] Convert all tasklets to workqueues


* Alexey Kuznetsov <kuznet@....inr.ac.ru> wrote:

> > as i said above (see the underlined sentence), hardirq contexts 
> > already run just fine with hardirqs enabled.
> 
> RENTRANCY PROTECTION! If does not matter _how_ they run, it matters 
> what context they preempt and what that context has to make to prevent 
> that preemption. [...]

again, there is no reason why this couldnt be done in a hardirq context. 
If a hardirq preempts another hardirq and the first hardirq already 
processes the 'softnet work', you dont do it from the second one but 
queue it with the first one. (into the already existing 
sd->completion_queue for tx work or queue->poll_list for rx work) It 
would be a simple additional flag in softnet_data.

once we forget about 'hardirq contexts run with irqs disabled', _there 
is just no technological point for softirqs_. They are an unnecessary 
abstraction!

once we concede that point, reentrancy protection does not have to be 
done via local_bh_disable(). For example we run just fine without it in 
-rt, local_bh_disable() is a NOP there. How is it done? By controlling 
execution of the _workflow_ that a softirq does. By implementing 
non-reentrancy via another, more flexible mechanism. (and by carefully 
fixing a few _other_, non-workflow assumptions that softnet does/did, 
such as the per-cpu-ness of softnet_data.)

Are we talking about the very same thing perhaps, just from a different 
angle? ;-)

	Ingo
-
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/