From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Tho mas Gleixner <tglx@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH] irq: remove IRQF_DISABLED
Date: Sat, 07 Mar 2009 08:40:36 +1100 [thread overview]
Message-ID: <1236375636.7260.160.camel@pasglop> (raw)
In-Reply-To: <1236358944.6326.538.camel@laptop>
> Ok, people put me straight here. Since linux not support interrupt
> priorities, wouldn't it simply be a matter of implementing
> local_irq_en/dis-able() as masking the lowest level you use to run
> normal interrupts on?
>
> That will leave your other interrupt level available as NMI/debug
> thingies.
No, you are missing some subtle things here.
local_irq_enable/disable() is about masking interrupts at the core
level. This will, on archs like powerpc, mask them -all- including the
timer for example, which is not sourced externally for us but comes from
a specific CPU facility and generates a different exception vector from
external interrupts. It also include to some extent perfmon interrupts
etc...
Now, once you get to -external- interrupts, there is one input line per
core/thread (some archs have more, and some powerpc variants also have a
second one for "critical" interrupts but let's not go there for now).
This line is controlled by a PIC, which can be one of many sorts, such
as the OpenMPIC (aka MPIC, popular on macs among other things), XICS
(newer pseries), etc...
Those PICs have a concept of priority (they don't all do, but on powerpc
it happens that a good chunk of them do). IE. individual external
interrupts can be prioritized. Also, because some of these are "smart"
PICs, (they use a fasteoi flow handler), they know whether an interrupt
is still being serviced and can handle priorities at eoi time. They
typically maintain a per-cpu current priority register internally,
raised when a CPU gets/acks an interrupt and lowered when that CPU does
an EOI).
So basically, you not only have the ability to control what interrupts
can nest what interrupts, but you -know- that at equal priorities, no
nesting will occur, which allows to fairly easily limit the amount of
nesting overall.
Hence, there is effectively no risk of uncontrolled nesting (unless it's
configured like shit which is always a possibility);
Now, as I proposed in an earlier email (maybe it got lost), if
uncontrolled nesting is what motivates you here, why not just change the
test of IRQF_DISABLED to also test for an arch hook, let's call it
arch_nest_irq(). Archs can hard wire that to 0 effectively enforcing
IRQF_DISABLED semantics on all interrupts. But you can be smarter and
look at how much stack space remains on your interrupt stack, and only
allow nesting if it's for example more than a couple of KBs.
Cheers,
Ben.
next prev parent reply other threads:[~2009-03-06 21:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-02 12:21 [RFC][PATCH] irq: remove IRQF_DISABLED Peter Zijlstra
2009-03-02 14:43 ` Ingo Molnar
2009-03-02 15:47 ` Matthew Wilcox
2009-03-02 15:59 ` Peter Zijlstra
2009-03-02 16:32 ` Matthew Wilcox
2009-03-02 21:01 ` Russell King
2009-03-02 21:17 ` Ingo Molnar
2009-03-02 21:17 ` Ingo Molnar
2009-03-02 17:11 ` Linus Torvalds
2009-03-02 17:55 ` Bartlomiej Zolnierkiewicz
2009-03-02 18:02 ` Peter Zijlstra
2009-03-02 18:07 ` Peter Zijlstra
2009-03-02 18:27 ` Bartlomiej Zolnierkiewicz
2009-03-02 18:29 ` Linus Torvalds
2009-03-02 18:48 ` Bartlomiej Zolnierkiewicz
2009-03-02 19:06 ` Linus Torvalds
2009-03-02 19:18 ` Bartlomiej Zolnierkiewicz
2009-03-02 17:56 ` Peter Zijlstra
2009-03-02 18:45 ` Vadim Lobanov
2009-03-02 18:45 ` Vadim Lobanov
2009-03-02 18:54 ` Linus Torvalds
2009-03-05 15:40 ` Mark Lord
2009-03-02 21:17 ` Alan Cox
2009-03-02 21:17 ` Alan Cox
2009-03-06 8:58 ` Benjamin Herrenschmidt
2009-03-06 9:12 ` Peter Zijlstra
2009-03-06 9:59 ` Benjamin Herrenschmidt
2009-03-06 10:05 ` Benjamin Herrenschmidt
2009-03-06 10:24 ` Peter Zijlstra
2009-03-06 17:02 ` Peter Zijlstra
2009-03-06 21:40 ` Benjamin Herrenschmidt [this message]
2009-03-02 17:55 ` Andrew Morton
2009-03-02 18:10 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1236375636.7260.160.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox