Re: [Xenomai-help] printk

[Philippe Gerum <rpm@xenomai.org>]

Philippe Gerum wrote:
> Dmitry Adamushko wrote:
> 
>> Philippe Gerum <rpm@xenomai.org> wrote on 14.11.2005 12:26:08:
>>
>>  > >>
>>  > >>Although, here is, well, a tiny race because of the fact that the 
>> virq
>>  > >>handler doesn't lock a buffer-related data (like 
>> __ipipe_printk_fill)
>>  > >>so a loss of data may occur under some circumstances.
>>  > >>
>>  >
>>  > Nope. __ipipe_printk_fill and friends are manipulated under hw irq
>>  > spinlocking
>>  > in printk(), and under Linux domain stalling protection in
>>  > __ipipe_flush_printk
>>  > since it's a virq handler,
>>
>> So what prevents some activity from the primary domain from preempting 
>> __ipipe_flush_printk() and calling printk() when _only_ the Linux 
>> domain is stalled?
> 
> 
> This cannot happen in async mode, since the output would be buffered and 
> printk() never called on behalf of the preempted handler.
> 
>>
>> let's say at the (*) point
>>
>> void __ipipe_flush_printk (unsigned virq)
>> {
>>       char *p = __ipipe_printk_buf;
>>       int out = 0, len;
>>
>>       clear_bit(IPIPE_PPRINTK_FLAG,&ipipe_root_domain->flags);
>>
>>       while (out < __ipipe_printk_fill) {
>>               len = strlen(p) + 1;
>>               printk("%s",p);
>>               p += len;
>>               out += len;
>>       }
>> (*) <---------------------------- preempted
>>       __ipipe_printk_fill = 0;
>> }
>>
>> When linux gets controll back the virq continues its execution and 
>> sets __ipipe_printk_fill up to 0.
>>
>> This cannot happen only if virqs are manipulated with the primary 
>> domain being stalled as well. But you told "and under __Linux 
>> domain___ stalling protection in __ipipe_flush_printk since it's a 
>> virq handler".
>>
>>
>>  > and finally, printk() cannot preempt
>>  > __ipipe_flush_printk under normal operation mode (i.e. async mode). 
>> AFAICS,
>>  > there's no race here.

Mea culpa, Dmitry is right, in the above situation he depicted, we could drop a 
portion of the output buffer. A way to fix this would be to hw lock a test and 
decrement section of __ipipe_printk_fill in the flush handler.

-- 

Philippe.