From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: adeos-main <adeos-main@gna.org>
Subject: Re: [Adeos-main] [BUG] evsync is not SMP-safe
Date: Fri, 25 Jan 2008 23:06:48 +0100 [thread overview]
Message-ID: <479A5D78.6040701@domain.hid> (raw)
In-Reply-To: <4788C279.1020607@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
Jan Kiszka wrote:
> Philippe,
>
> this
>
> int fastcall __ipipe_dispatch_event (unsigned event, void *data)
> ...
> ipipe_cpudom_var(next_domain, evsync) |= (1LL << event);
> local_irq_restore_hw(flags);
> propagate = !evhand(event, start_domain, data);
> local_irq_save_hw(flags);
> ipipe_cpudom_var(next_domain, evsync) &= ~(1LL << event);
>
> doesn't fly on SMP. While the invoked event handler is running, it may
> happen that the caller gets migrated to another CPU. The result is an
> inconsistent evsync state that causes ipipe_catch_event to stall (test
> case: invoke Jerome's system() test a few times, them try to unload
> Xenomai skins and nucleus).
>
> First idea (I've nothing implemented to far, would happily leave it to
> someone else's hand): Track event handler entry/exit with an, say, 8 bit
> per-cpu counter. On event deregistration, just summarize over the
> per-cpu counters and wait for the sum to become 0. This has just the
> drawback that it may cause livelocks on large SMP boxes when trying to
> wait for a busy event. I've no perfect idea so far.
Second approach to solve this (currently) last known ipipe issue cleanly:
As long as some task in the system has __ipipe_dispatch_event (and thus
some of the registered event handlers) on its stack, it is not safe to
unregister some handler. For simplicity reasons, I don't think we should
make any difference which handlers are precisely busy. So, how to find
out if there are such tasks?
I checked the code and derived three classes of preconditions for the
invocation of __ipipe_dispatch_event:
1) ipipe_init_notify and ipipe_cleanup_notify -> no preconditions
2) ipipe_trap_notify -> some Linux task has PF_EVNOTIFY set or
there are tasks with custom stacks present
3) all other invocations -> some Linux task has PF_EVNOTIFY set
This means by walking the full Linux task list and checking that are no
more PF_EVNOTIFY-tasks present, we can easily exclude 3). In fact, 2)
can also be excluded this way because we can reasonably demand that any
I-pipe user fiddling with event handlers has killed all non-Linux tasks
beforehand. This leaves us with 1) which should be handled via classic
RCU as Linux offers it. Viable? It would even shorten the fast path a bit!
Still no code, I would like to collect feedback on this new idea first.
Jan
PS: IPIPE_EVENT_INIT is not used by Xenomai (and I found no trace that
it ever was). Can we deprecate this event and then remove it later,
Philippe?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
next prev parent reply other threads:[~2008-01-25 22:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-12 13:36 [Adeos-main] [BUG] evsync is not SMP-safe Jan Kiszka
2008-01-25 22:06 ` Jan Kiszka [this message]
2008-01-27 15:24 ` Jan Kiszka
2008-01-28 6:59 ` Philippe Gerum
2008-01-28 8:35 ` 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=479A5D78.6040701@domain.hid \
--to=jan.kiszka@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.