Re: [Xenomai-help] mlockall error after calling mlockall()

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

[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Same issue exists in user space. And rt_cond_wait_inner needs fixing.
>>>>>> And then there is a spurious sign inversion:
>>>>>>
>>>>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c
>>>>>> index 478321d..f874678 100644
>>>>>> --- a/src/skins/native/cond.c
>>>>>> +++ b/src/skins/native/cond.c
>>>>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout)
>>>>>>  				&saved_lockcnt, XN_REALTIME, &timeout);
>>>>>>  
>>>>>>  	while (err == -EINTR)
>>>>>> -		err = -XENOMAI_SKINCALL2(__native_muxid,
>>>>>> -					 __native_cond_wait_epilogue, mutex,
>>>>>> -					 saved_lockcnt);
>>>>>> +		err = XENOMAI_SKINCALL2(__native_muxid,
>>>>>> +					__native_cond_wait_epilogue, mutex,
>>>>>> +					saved_lockcnt);
>>>>>>  #endif /* !CONFIG_XENO_FASTSYNCH */
>>>>> Ok for the sign inversion, but in this case the status is Ok. We call
>>>>> cond_wait_epilogue only if prologue returned -EINTR, and update the
>>>>> status, this is what we want.
>>>>>
>>>>> There is only one way out which will not break the ABI: do not call
>>>>> cond_wait_epilogue in the kernel-space cond_wait_prologue.
>>>>>
>>>> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait an
>>>> -EINTR on mutex lock, we lose the former, don't we?
>>>>
>>>> If we can't find a workaround, I'm for breaking the ABI for this
>>>> particular service - but let's search for an alternative first.
>>>>
>>> The only way around ABI changes: save the return code of cond_wait
>>> /somewhere/ across prologue and epilogue syscalls - but where???
>>>
>> In-kernel RT_TASK, that's probably the only place. Once
>> __rt_cond_wait_epilogue has acquired the mutex (or failed without
>> receiving a -EINTR), it can then pick up the original error that this
>> task received from rt_cond_wait_prologue and return it. What do you think?
> 
> I was thinking about the same idea, by using the xnthread errno.
> However, it is not reentrant, in the sense that if a signal handler
> emits a syscall which overrides this value, we are toast.

Right. But that's the price someone unable/unwilling to update their
user space libs along with the next kernel update will have to pay. I
don't expect there are many, though, and the sketched scenario is fairly
uncommon as well.

So let's head this way: Install some workaround for the existing
__rt_cond_wait_prologue syscall, but also introduce
__rt_cond_wait_prologue2 which writes the cond-wait error code back like
it already happens for lockcnt. That syscall is used by updated user
space libs if they find it, otherwise we fall back to the old pattern.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]