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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main

Reply via email to