From: Jan Kiszka <jan.kiszka@domain.hid>
To: rpm@xenomai.org
Cc: adeos-main@gna.org, Xenomai-core@domain.hid
Subject: Re: [Xenomai-core] [Adeos-main] [PATCH] i386: switch to root domain on unhandled non-root faults
Date: Tue, 06 Nov 2007 07:16:56 +0100 [thread overview]
Message-ID: <473006D8.4080808@domain.hid> (raw)
In-Reply-To: <472F990A.2030209@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> This patch addresses the recently discovered issue that I-pipe actually
>>> need to deal with faults over non-root domain in which the current
>>> domain shows no interest in. Such faults could be triggered inside
>>> copy_*_user, thus can cleanly be handled by Linux - if we only allow for
>>> this. Currently, if debugging is on, we warn about a potential bug, and
>>> corrupt the pipeline states otherwise.
>>>
>>> The new approach is to unconditionally drop to root domain in such
>>> cases, but - for debugging purposes of non-fixable faults - keep track
>>> of the original domain and report it on oops.
>>>
>>> Similar patches are required for other archs. Maybe I can look into
>>> x86_64 later.
>>>
>
> Nak, this patch would not work as wanted. Again, what you need is to
> always fixup, and conditionally send a bug report to the kernel log if
> CONFIG_IPIPE_DEBUG is enabled, nothing more.
>
> This patch assumes that die() is always going to be fired for any
> in-kernel fault, so that all reports only need to go through this
> routine, which is wrong. Kernel fixups through exception tables may fix
> the fault early and silently, and this is particularly the case for
> copy_to_user helpers, which do include kernel fixup code. By being
> silent when fixing up things in __ipipe_handle_exception() like your
> patch currently is, we would be left with no trace at all that some
> unhandled fault just happened, except by looking at /proc/xenomai/faults.
As you are still remain vague on the actual problematic scenarios, I
will try to go through them, and maybe you can add/correct what I miss:
- faults in user land => can be silently handled by Linux after
dropping to root domain. This lowering is perfectly fine as the
higher domains showed no interest in the fault, thus are currently
running in domain-agnostic code paths anyway.
- faults on fixable kernel addresses => same as above. If the high
domains fail to evaluate the fix-up result, it's not I-pipe's fault.
- minor faults on kernel addresses (more precisely: in the I-pipe core
or some I-pipe user) => those would now went unnoticed and need
further thoughts, granted.
- major faults on kernel addresses => still generate major oopses and
will thus be visible.
Did I missed something? If not, I would now start addressing the
remaining problematic scenario directly instead of throwing all into the
same pot.
>
> By sending the report immediately when fixing up in the latter routine,
> you also avoid the ugly ipipe_orig_domain stuff.
It's not nice, but it is at least as ugly as reporting a kernel BUG when
there is only a gracefully fixable bug in user code. I definitely do not
agree with your approach as well, and I'm convinced we need to find a
third way here.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
next prev parent reply other threads:[~2007-11-06 6:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-05 19:16 [Xenomai-core] [PATCH] i386: switch to root domain on unhandled non-root faults Jan Kiszka
2007-11-05 19:23 ` [Xenomai-core] [Adeos-main] " Jan Kiszka
2007-11-05 22:28 ` Philippe Gerum
2007-11-06 6:16 ` Jan Kiszka [this message]
2007-11-06 9:01 ` Jan Kiszka
2007-11-08 13:48 ` Jan Kiszka
2007-11-08 23:31 ` Philippe Gerum
2007-11-09 13:58 ` Jan Kiszka
2007-11-09 16:46 ` Philippe Gerum
2007-11-09 17:07 ` Jan Kiszka
2007-11-09 17:31 ` Philippe Gerum
2007-11-11 18:59 ` Jan Kiszka
2007-11-13 10:28 ` Philippe Gerum
2007-11-13 17:40 ` Jan Kiszka
2007-11-19 11:59 ` Philippe Gerum
2007-11-19 12:42 ` Jan Kiszka
2007-11-13 21:32 ` Gilles Chanteperdrix
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=473006D8.4080808@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-core@domain.hid \
--cc=adeos-main@gna.org \
--cc=rpm@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.