Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : Native: Fix return code of in-kernel rt_cond_wait[_until]

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

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>>>> Ok for returning -EINTR, it is documented. Kernel-space is not so
>>>>>>>>>> different from user-space, rt_task_unblock could wake-up a kernel-space
>>>>>>>>>> task blocked in a call to rt_cond_wait.
>>>>>>>>>>
>>>>>>>>>> However, if the epilogue returns an error, we must return it.
>>>>>>>>>>
>>>>>>>>> OK for this. Pushed an update, but I also modified it further to avoid
>>>>>>>>> returning without the mutex lock unless that one is also failing. Maybe
>>>>>>>>> in-kernel POSIX requires the same fix, will check.
>>>>>>>> Still not OK. You should reacquire the mutex only if the error is 0,
>>>>>>>> -ETIMEDOUT or -EINTR. With any other error, we do not know if we can
>>>>>>>> call the epilogue safely.
>>>>>>> We _must_ reacquire the mutex - but, granted, we actually have to take
>>>>>>> care of invalid cond objects. Lot's of bugs...
>>>>>> No. If the error is another error than 0, -ETIMEDOUT, or -EINTR, it
>>>>>> means that the error was detected prior to freeing the mutex. So, we do
>>>>>> not have to re-acquire the mutex. Quoting POSIX:
>>>>>>
>>>>>> "Except in the case of [ETIMEDOUT], all these error checks shall act as
>>>>>> if they were performed immediately at the beginning of processing for
>>>>>> the function and shall cause an error return, in effect, prior to
>>>>>> modifying the state of the mutex specified by mutex or the condition
>>>>>> variable specified by cond."
>>>>>>
>>>>>> POSIX does not talk about -EINTR, because it states that in this case,
>>>>>> we should return 0 to the application.
>>>>> OK, but EIDRM was missing in your list. Will adjust both patches.
>>>> No, EIDRM is part of the "other errors than ETIMEDOUT and 0"
>>>>
>>> I interpret the spec fairly differently here: It states that we have to
>>> leave the mutex state behind *as if* the error was already detected on
>>> entry - thus we are expected to restore its state.
>> No. We must return prior to modifying its state. Not change its state
>> then restore it.
>>
>> There is no EIDRM anyway, I return 0, and the user gets EINVAL when
>> calling pthread_cond_wait again.
> 
> No, this is not even the way it works. EIDRM can not happen, because
> pthread_cond_destroy will return EBUSY as long as a thread is blocked in
> a call to pthread_cond_wait. This is allowed by POSIX.
> 

Right, POSIX is fine as is. Native is still different, though.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux