linux-kernel - Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 20 Nov 2006 08:25:54 -0800
From:	Daniel Walker <dwalker@...sta.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Ingo Molnar <mingo@...e.hu>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org, dwalker@...sta.com
Subject: Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi
	type IRQ handlers

On Mon, 2006-11-20 at 11:01 +0100, Ingo Molnar wrote:

> correct. It's basically a different type of 'flow' of handling an 
> interrupt. It's a host-side genirq-level detail that should have no 
> irqchip level impact at all.
> 
> The only detail is that sometimes a threaded flow /cannot/ be 
> implemented if the irqchip lacks certain methods. (such as a 
> mask/unmask)
> 
> i.e. Sergei's patch tweaking the irqchip data structures is wrong - the 
> correct approach is what i do for i386/x86_64: install a different 
> "threaded" flow handler. I prefer this to tweaking the existing 
> 'fasteoi' handler, to make the act of supporting a threaded flow design 
> explicit. (and to allow a mixed threaded/non-threaded flow setup) I 
> didnt take Daniel's prior patch for that reason: he tried to tweak the 
> fasteoi flow handler - which is an almost good approach but not good 
> enough :-)
> 

It makes porting to powerpc for instance harder because some controllers
have ack(), and some don't.. Some have mask(), and some don't.. So you
end up with what Sergei is doing which is flat out make ack == eoi ..
Where you have multiple irq chip types each one really needs an
individual evaluation ..

I don't really agree with your method since it increase the porting
effort, and I don't see a gain from it.. In fact the changes that you
make seem like it would be more difficult to support a simple reversal
from a thread to an interrupt context handler, since your permanently
changing the "flow handler" , as you called it, no matter what the
context is. So the person using this code will have to investigate this
new flow handler, which will result is a very anti-climactic ending and
lots of useless work since it's really making ack == eoi (at least for
powerpc). 

Daniel

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