On 2011-06-23 13:29, Gilles Chanteperdrix wrote:
> On 06/23/2011 11:09 AM, Jan Kiszka wrote:
>> On 2011-06-23 11:05, Gilles Chanteperdrix wrote:
>>> On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>>>>> +#ifdef CONFIG_XENO_FASTSYNCH
>>>>> + if (xeno_get_current() != XN_NO_HANDLE &&
>>>>> +     !(xeno_get_current_mode() & XNRELAX) && buf_pool_get()) {
>>>>> +         struct print_buffer *old;
>>>>> +
>>>>> +         old = buf_pool_get();
>>>>> +         while (old != buffer) {
>>>>> +                 buffer = old;
>>>>> +                 old = buf_pool_cmpxchg(buffer, buffer->pool_next);
>>>>
>>>> Though unlikely, it's still possible: The buffer obtained in the last
>>>> round may have been dequeued meanwhile and then freed (in case a third
>>>> buffer was released to the pool, filling it up to pool_capacity).
>>>
>>> I do not get it: it seems to me that if the current head (that is
>>> buf_pool_get()) is freed, then the cmpxchg will fail, so we will loop
>>> and try again.
>>
>> Problematic is the dereferencing of the stale buffer pointer obtained
>> during the last cmpxchg or via buf_pool_get. This happens before the new
>> cmpxchg.
> 
> Ok. Got it, that would be a problem only if the stale pointer pointed to
> an unmapped area, but ok, better avoid freeing the buffers. I guess it
> would not be a problem as applications tend to have a fixed number of
> threads anyway.

That is a risky assumption, proven wrong e.g. by one of our
applications. Threads may always be created or destroyed depending on
the mode of an application, specifically if it is a larger one.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to