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]

Message-Id: <1163970524.5826.128.camel@localhost.localdomain>
Date:	Mon, 20 Nov 2006 08:08:43 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
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


>     I'm not sure it's feasible. The idea behind level/edge flows is to 
> eliminate the interrupt priority I think. That's why they EOI ASAP (with the 
> level handler masking IRQ before that) -- this way the other interrupts may 
> come thru.

Well, the idea behind the level/edge flow is not exactly that afaik.
It's more like having tailored handlers for level/edge on PICs that are
not intelligent to auto-mask with a priority mecanism (ie. dumb PICs
which are very common in the embedded field, and for example, on ARM
where genirq takes its roots).

>     I used to think that fasteoi was intended for SMP PICs which are 
> intelligent enough to mask off the interrupts pending delivery or handling on 
> CPUs and unmask them upon receiving EOI -- just like x86 IOAPIC does.

In general, PICs that are intelligent enough to mask off, wether using
something as you describe or using priorities. I don't feel the need of
going through hoops to allow lower or same priority interrupts in.
First, if you really need an interrupt to be serviced quick, then you
can just give it a higher priority. In the general case however, I do
-not- want to allow interrupts to stack up. Imagine a big IBM machine
with hundreds interrupt lines, what happens to the kernel stack if we
let them interrupt each other ?

>  This 
> way, the acceptance of the lower priority interrupts shouldn't be hindered on 
> the other CPUs. Maybe the scheme is different for OpenPIC (I know it has the 
> different interrupt distribution scheme from IOAPIC)?

I don't think there is a real need to let lower priority interrupts in
on a CPU that is currently handling a higher priority one.

In the case of RT, though, with delayed delivery, then, the option to
mask and EOI right away is always possible.

Ben.



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