Jan Kiszka wrote: > Philippe Gerum wrote: >> Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> Jan Kiszka wrote: >>>>> commit 728fc8970e2032b3280971788f1223f3ad82d80d >>>>> Author: Jan Kiszka <jan.kis...@siemens.com> >>>>> Date: Thu Jan 15 11:10:24 2009 +0100 >>>>> >>>>> xnpipe: Fix racy callback handlers >>>>> >>>>> Invocation of input, output and alloc handler must take place under >>>>> nklock to properly synchronize with xnpipe_disconnect. Change all >>>>> callers to comply with this policy. >>>>> >>>> That one is under investigation. I agree on the bug report (thanks btw), >>>> but I >>>> disagree on the fix. Basically, we can't run all hooks under nklock. For >>>> instance, the alloc_handler may issue kmalloc() calls when issued from the >>>> Linux >>>> write endpoint. >>> You mean it /could/? Because no in-tree user (ie. native) calls >>> rt-unsafe services from its alloc_handler. >>> >> When you export a public interface, it is better not to make it incompatible >> unless there is no other way to fix a situation. Doing so is last resort for >> me. > > OTH, there is nothing documented yet about those callback handlers or > xnpipe_connect. So we could only break _assumptions_ about this > interface.
Actually, we would break existing implementations, but I understand your point. But, of course, I would be happy if we could continue to keep > the critical section length short. I just don't see how to achieve this > without significant restrictions on the callback handlers and their use > cases. > That is because the semantics of those callouts is not that smart. If we have to break the API to solve the locking issue, I want to get the semantics fixed in the same move (which may help a lot in solving the locking issue as well), so we don't end up with two subsequent breakage. > Jan > -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
