Re: [Xenomai-core] Racy pse51_mutex_check_init?

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Hi Gilles,
>>>>>>
>>>>>> trying to understand the cb_read/write lock usage, some question came up
>>>>>> here: What prevents that the mutexq iteration in pse51_mutex_check_init
>>>>>> races against pse51_mutex_destroy_internal?
>>>>>>
>>>>>> If nothing, then I wonder if we actually have to iterate over the whole
>>>>>> queue to find out whether a given object has been initialized and
>>>>>> registered already or not. Can't this be encoded differently?
>>>>> We actually iterate over the queue only if the magic happens to be
>>>>> correct, which is not the common case.
>>>> However, there remains a race window with other threads removing other
>>>> mutex objects in parallel, changing the queue - risking a kernel oops.
>>>> And that is what worries me. It's unlikely. but possible. It's unclean.
>>> Ok. This used to be protected by the nklock. We should add the nklock again.
>> Well I do not think that anyone is rescheduling, so we could probably
>> replace the nklock with a per-kqueue xnlock.
> 
> If nklock or per queue - both will introduce O(n) at least local
> preemption blocking. That's why I was asking for an alternative
> algorithm than iterating over the whole list.

I insist:
- the loop does almost nothing, so n will have to become very large for
it to take a long time, and n is the number of mutexes allocated so far
in one application, or the number of shared mutexes, which is probably
even less.
- the loop happens if the magic happens to be good, so probably only if
you are calling pthread_mutex_init twice for the same mutex, the normal
use-case is to use memory from BSS to allocate mutex, so the magic of a
normal application calling pthread_mutex_init is always 0, and you do
not enter the loop.

Today, I consider it much more a problem that I can not call fork in a
xenomai application with opened descriptors and exit the parent
application without the file descriptors being closed in the child too.
And this will be the thing I will spend time to fix first. Using the
registry in the posix skin will only come next.

-- 
					    Gilles.