Re: [Xenomai-core] Pending patches

[Jan Kiszka <jan.kiszka@domain.hid>]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
>>>> commit 728fc8970e2032b3280971788f1223f3ad82d80d
>>>> Author: Jan Kiszka <jan.kiszka@domain.hid>
>>>> 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