From: Philippe Gerum <rpm@xenomai.org>
To: Philippe Gerum <rpm@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, xenomai@xenomai.org
Subject: Re: resume_oob_task & not actually resuming
Date: Wed, 30 Jun 2021 19:52:18 +0200 [thread overview]
Message-ID: <87tulfgrzh.fsf@xenomai.org> (raw)
In-Reply-To: <87wnqbgs91.fsf@xenomai.org>
Philippe Gerum via Xenomai <xenomai@xenomai.org> writes:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> Hi Philippe,
>>
>> need you guidance here to fix the "thread ... switched to non-rt CPU,
>> aborted" issue:
>>
>> For some reason, I-pipe is fine and kicks the migrating non-rt task
>> again when ipipe_migration_hook() does not resume the target thread due
>> to failing cobalt_affinity_ok() check. Over dovetail, this is not
>> working, and the thread is stuck in nirvana, i.e. suspended as hardened
>> from Linux POV but not resumed on the Xenomai side. Looking at how
>> finalize_oob_transition() is called in the dovetail kernel, it does not
>> seem like it is prepared for not being in oob after that call
>> (finish_task_switch is not called - not sure if that makes the difference).
>>
>> So, either the point of checking and failing the migration in Xenomai is
>> wrong for dovetail, or we need some extension of the latter to account
>> for that case. What was the intended design?
>>
>
> Dovetail has it right, Cobalt is wrong in this case. Cobalt-wise: we
> should always 1) raise a cancellation request upon any issue with
> switching to the oob stage on behalf of resume_oob_task(), 2) lift the
> XNRELAX suspension bit, 3) detect the pending cancellation in
> xnshadow_harden(), forcing the current thread to exit. I did not dive
> into the details yet, but I suspect that Cobalt might be lucky with the
> I-pipe in skipping xnthread_resume() upon failure (some pending signal,
> forcing sigwake maybe?).
>
> IOW, we should complete the switch to oob in any case, then kick out the
> thread with a bad affinity when unwinding from xnshadow_harden().
Of course, this means that all runqueues must be built for all possible
CPUs, NOT restricted to the CPUs which are part of the oob-capable
set. Cobalt sets up a runqueue for each online CPU in xnsched_init_all()
which is more restrictive, but that should still work provided the
hot-plug scenario is dismissed.
--
Philippe.
next prev parent reply other threads:[~2021-06-30 17:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 15:56 resume_oob_task & not actually resuming Jan Kiszka
2021-06-30 17:46 ` Philippe Gerum
2021-06-30 17:52 ` Philippe Gerum [this message]
2021-07-01 6:11 ` Jan Kiszka
2021-07-01 7:29 ` Philippe Gerum
2021-07-01 7:40 ` Jan Kiszka
2021-07-01 8:08 ` Philippe Gerum
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=87tulfgrzh.fsf@xenomai.org \
--to=rpm@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.