From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Auel, Kendall" <Kendall.Auel@3DSystems.Com>,
"xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks
Date: Thu, 20 Dec 2018 11:45:25 +0100 [thread overview]
Message-ID: <4aebca73-7231-e92f-2424-0d44ee12e2a8@siemens.com> (raw)
In-Reply-To: <70702a6f3a2e47e58a54bc88e8298caf@P10-EX02.3DSystems.Internal>
On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
> Jan,
>
> I'm very much in favor of providing a way to prevent Xenomai modules from using features which can result in deadlock, if there is a clean way to detect such a situation.
>
> We used gettimeofday in one of our modules and it mostly worked great. But once in a great while the system would deadlock. Most calls to gettimeofday are benign and appear to work normally, which is why it is especially problematic. It would have saved some debug cycles if there was a kernel log message to warn us of our danger.
>
> Or perhaps we could collect a blacklist of references which will produce warnings when linking a Xenomai module. All of these things are 'nice to have' but certainly not urgent matters.
We do have the infrastructure and a small use case for such RT traps already: If
you use --mode-check on xeno-config, any usage of malloc and free from RT
contexts will be detected and reported. These calls are evil as well because
they tend no not trigger a syscall in the fast path and only fail on contention
or empty-pool situations of the userspace allocator.
We could extend that mechanism for gettimeofday & Co. checks, but we need to
limit that to non-posix applications: with posix, you are already redirected to
the RT-safe implementations of those functions.
Patches welcome.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2018-12-20 10:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 10:20 Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks Lange Norbert
2018-12-19 12:09 ` Philippe Gerum
2018-12-19 12:44 ` Jan Kiszka
2018-12-19 13:08 ` Lange Norbert
2018-12-19 13:47 ` Philippe Gerum
2018-12-19 18:26 ` Auel, Kendall
2018-12-20 10:45 ` Jan Kiszka [this message]
2018-12-20 12:29 ` Lange Norbert
2018-12-20 13:32 ` Jan Kiszka
2018-12-20 15:02 ` Lange Norbert
2018-12-20 15:21 ` Jan Kiszka
2018-12-21 13:31 ` Lange Norbert
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=4aebca73-7231-e92f-2424-0d44ee12e2a8@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=Kendall.Auel@3DSystems.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.