From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Xenomai <xenomai@xenomai.org>
Subject: Re: [Xenomai] ipipe: issues with ARM exception handling
Date: Mon, 23 Feb 2015 21:43:22 +0100 [thread overview]
Message-ID: <54EB90EA.4030401@xenomai.org> (raw)
In-Reply-To: <20150223171250.GE22377@hermes.click-hack.org>
On 02/23/2015 06:12 PM, Gilles Chanteperdrix wrote:
> On Mon, Feb 23, 2015 at 06:01:54PM +0100, Philippe Gerum wrote:
>>> hard_local_irq_disable() should always be called in case entry.S
>>> expects us to return as we entered: with hw irqs off
>>
>> Which is what ipipe_fault_exit() does by testing the mangled state. If
>> the fault entered with virtual IRQs on, then you must exit with both the
>> stall bit and CPSR_I bit cleared.
>
> Absolutely not. Imagine a Linux task, with root unstalled
> experiencing a fault. entry.S is entered root is still unstalled,
> with hardware irqs off. On fault entry, we must reflect this
> hardware irq state on the stall bit and enable hw irqs. Then when
> the fault is handled, undo that, unstall the root stage, disable hw
> irqs and return to entry.S, so that it may resume the execution of
> the Linux task. If it returns quickly to user-space, a stalled root
> at this point would be a disaster, because nothing, certainly not
> entry.S will unstall the root stage.
>
> Then there is the case where Linux re-enables irqs in the course of
> the handler, in that case, we should not return to entry.S with hw
> irqs off.
>
Since Linux re-enables hw irqs in the course of the handler with a
regular kernel, and never restores any masked state in this case before
returning to entry.S, don't you think that the fault entry code in
entry.S is aware of such possibility? If so, why would restoring a
masked hw state be absolutely required when the pipeline is enabled?
--
Philippe.
next prev parent reply other threads:[~2015-02-23 20:43 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 18:03 [Xenomai] ipipe: issues with ARM exception handling Jan Kiszka
2015-02-20 18:13 ` Gilles Chanteperdrix
2015-02-20 18:17 ` Jan Kiszka
2015-02-20 18:19 ` Jan Kiszka
2015-02-20 19:44 ` Philippe Gerum
2015-02-20 19:47 ` Philippe Gerum
2015-02-20 19:52 ` Philippe Gerum
2015-02-23 16:06 ` Jan Kiszka
2015-02-23 16:32 ` Philippe Gerum
2015-02-23 16:37 ` Gilles Chanteperdrix
2015-02-23 16:50 ` Jan Kiszka
2015-02-23 16:52 ` Gilles Chanteperdrix
2015-02-23 17:02 ` Jan Kiszka
2015-02-23 17:14 ` Gilles Chanteperdrix
2015-02-23 17:38 ` Jan Kiszka
2015-02-23 17:49 ` Jan Kiszka
2015-02-23 17:52 ` Jan Kiszka
2015-02-23 18:30 ` Jan Kiszka
2015-02-24 16:23 ` Jan Kiszka
2015-02-24 16:45 ` Gilles Chanteperdrix
2015-02-24 16:46 ` Jan Kiszka
2015-02-24 16:50 ` Gilles Chanteperdrix
2015-02-23 16:55 ` Gilles Chanteperdrix
2015-02-23 17:01 ` Philippe Gerum
2015-02-23 17:12 ` Gilles Chanteperdrix
2015-02-23 17:21 ` Gilles Chanteperdrix
2015-02-23 17:43 ` Jan Kiszka
2015-02-23 17:51 ` Gilles Chanteperdrix
2015-02-23 17:54 ` Jan Kiszka
2015-02-23 18:04 ` Gilles Chanteperdrix
2015-02-23 18:11 ` Gilles Chanteperdrix
2015-02-23 18:16 ` Jan Kiszka
2015-02-23 18:32 ` Jan Kiszka
2015-02-23 18:34 ` Gilles Chanteperdrix
2015-02-23 19:14 ` Jan Kiszka
2015-02-23 19:18 ` Gilles Chanteperdrix
2015-02-23 18:33 ` Gilles Chanteperdrix
2015-02-23 19:13 ` Gilles Chanteperdrix
2015-02-23 20:25 ` Philippe Gerum
2015-02-23 20:27 ` Gilles Chanteperdrix
2015-02-23 20:33 ` Philippe Gerum
2015-02-23 20:38 ` Gilles Chanteperdrix
2015-02-23 20:49 ` Philippe Gerum
2015-02-23 20:54 ` Gilles Chanteperdrix
2015-02-23 20:43 ` Philippe Gerum [this message]
2015-02-23 20:46 ` Gilles Chanteperdrix
2015-02-23 17:02 ` Gilles Chanteperdrix
2015-02-20 18:38 ` Gilles Chanteperdrix
2015-02-20 18:51 ` Jan Kiszka
2015-02-20 18:53 ` Gilles Chanteperdrix
2015-02-20 18:57 ` Jan Kiszka
2015-02-20 18:59 ` Gilles Chanteperdrix
2015-02-20 19:04 ` Jan Kiszka
2015-02-21 9:13 ` Philippe Gerum
2015-02-23 15:59 ` Jan Kiszka
2015-02-23 16:29 ` Philippe Gerum
2015-02-23 16:58 ` Jan Kiszka
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=54EB90EA.4030401@xenomai.org \
--to=rpm@xenomai.org \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.