From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
Date: Thu, 01 May 2008 17:53:43 +1000 [thread overview]
Message-ID: <1209628423.18023.286.camel@pasglop> (raw)
In-Reply-To: <A9B566F7-D00B-4202-9B85-427C38EE6070@kernel.crashing.org>
On Thu, 2008-05-01 at 01:01 -0500, Kumar Gala wrote:
> On Apr 30, 2008, at 6:47 PM, Paul Mackerras wrote:
> > Kumar Gala writes:
> >
> >> If we don't handle reschedule or signal will we actually not function
> >> properly? I assume reschedule isn't an issue, but could we lose a
> >> signal?
> >
> > It depends on whether a critical or machine check handler can ever do
> > anything to generate a signal or a reschedule. If they can't, then
> > there is no problem.
>
> They can if the come from user space. I'm question what it means to
> send a signal based on receiving an async exception.
For "normal" async exceptions (ie. external interrupts), it could be
anything... EE -> network rx -> SIGIO, or you get out of EE, hit the
softirq path, figure out there was something there waiting processing
(ie, some tty task) and that results in a signal being sent...
> So we have 4 actual exceptions:
> * CriticalInput (some external device signaled this. There are two
> concepts of critical. One is error the other is high priority)
> However this would have the same caveats as any ExternalInput handler.
No, it's worse. It can interrupt code that normally has
local_irq_disabled() and thus doesn't expect to be interrupted. That
means that everything becomes unsafe including locks etc....
Note that driver that want to make active use of that probably want some
explicit local_crit_irq_disable/enable functions to be able to implement
some sort of synchronization.
> * Watchdog - pretty severe if this fires.
>
> * Debug - user space debug is pretty straight forward. However we
> have features like kprobes that require kernel level support.
Which means we have to be extra careful, in fact, I consider it a design
bug of BookE to have made debug be a critical interrupt...
> * MachineCheck - pretty serve if this fires.
>
> So I'm not if there is any good way to preclude the handlers
> associated with these exceptions from doing the things you listed.
Ben.
next prev parent reply other threads:[~2008-05-01 7:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 9:27 [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code Kumar Gala
2008-04-30 21:54 ` Benjamin Herrenschmidt
2008-04-30 22:13 ` Kumar Gala
2008-04-30 22:18 ` Benjamin Herrenschmidt
2008-04-30 23:24 ` Kumar Gala
2008-04-30 22:22 ` Benjamin Herrenschmidt
2008-04-30 23:28 ` Kumar Gala
2008-04-30 23:52 ` Benjamin Herrenschmidt
2008-04-30 23:47 ` Paul Mackerras
2008-05-01 6:01 ` Kumar Gala
2008-05-01 7:53 ` Benjamin Herrenschmidt [this message]
2008-05-01 13:22 ` Kumar Gala
2008-05-01 14:26 ` Josh Boyer
2008-05-01 14:31 ` Kumar Gala
2008-05-05 11:57 ` Gabriel Paubert
2008-05-05 12:06 ` Benjamin Herrenschmidt
2008-05-01 8:24 ` Paul Mackerras
2008-05-01 13:17 ` Kumar Gala
2008-05-01 16:14 ` Scott Wood
2008-05-01 16:22 ` Scott Wood
2008-05-01 16:33 ` Kumar Gala
2008-05-01 16:42 ` Scott Wood
2008-05-01 17:48 ` Kumar Gala
2008-05-01 19:02 ` Scott Wood
2008-05-01 23:34 ` Paul Mackerras
2008-05-02 4:02 ` Kumar Gala
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=1209628423.18023.286.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).