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. 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. Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
