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.

> 
>>> @@ -346,12 +396,36 @@ static void cleanup_buffer(struct print_buffer 
>>> *buffer)
>>>  {
>>>     struct print_buffer *prev, *next;
>>>  
>>> +   assert_nrt();
>>> +
>>>     pthread_setspecific(buffer_key, NULL);
>>>  
>>>     pthread_mutex_lock(&buffer_lock);
>>>  
>>>     print_buffers();
>>
>> You also need to unhook the buffer from the active list before returning
>> it to the pool.
> 
> We can not do that: we want that when rt_print_init takes a buffer from
> the pool, it does not need to do any operation which would need to
> switch to secondary mode. This includes getting the active list mutex.
> So, the buffer in the pool are also in the active list, but they remain
> empty, so, nothing will be printed.

Ah, I see.

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