linux-kernel - Re: [patch 4/4] genirq: add support for threaded interrupt handlers

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

Message-ID: <49A94032.9010105@s5r6.in-berlin.de>
Date:	Sat, 28 Feb 2009 14:46:26 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, mingo@...e.hu,
	jonathan@...masters.org
Subject: Re: [patch 4/4] genirq: add support for threaded interrupt handlers

Steven Rostedt wrote:
> The way softirqs are currently designed, you can not run them from
> the irq thread. We discovered this (the hard way) in the preempt-rt 
> kernel. The issue is that each softirq (threaded in preempt-rt, with a 
> thread for every CPU. ie. net-rx/0 net-rx/1 net-rx/2 net-rx/3 for a 4 CPU 
> box) is bound to a specific CPU. The design is to modify per cpu data. If 
> a IRQ thread were to run the softirq code and migrate to another CPU, you 
> will have very hard to debug crashes on your hands.

I presume that a lot of tasklet users rely on the fact that tasklets are
executed on the CPU which scheduled them.  (E.g. the firewire stack's
low level currently does.)

> We also tried to bind the IRQ thread to the CPU if it were to run a 
> softirq. But that too had issues. If the IRQ thread was bound to a CPU and 
> a higher priority process preempted it, that IRQ handler could not migrate 
> to another CPU to finish the work. Now the IRQ handler would need to wait 
> for that high priority process to give up the CPU in order to continue.
> 
> The solution is to redesign the softirq code to handle migration.

Do you mean "redesign the softirq framework" or "redesign the softirq
framework users"?

(In the particular case of firewire, the latter should be just fine.)
-- 
Stefan Richter
-=====-==--= --=- ===--
http://arcgraph.de/sr/
--
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/