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


Xenomai-core mailing list

Reply via email to