Re: [Xenomai-help] printk

[Philippe Gerum <rpm@xenomai.org>]

Ignacio García Pérez wrote:
> Dmitry Adamushko wrote:
> 
> 
>>xenomai-help-bounces@domain.hid wrote on 11.11.2005 10:30:26:
>>
>>
>>>Hi,
>>>
>>>I'm porting an app from RTAI to Xenomai, and when it came to the
>>>rt_printk function, I had to replace it with plain printk (the
>>>xnarch_log* functions all use printk).
>>>
>>>What I want to know if:
>>>
>>>1- Is totally safe to call the standard kernel printk function from a
>>>real time task?
>>
>>Actually, the adeos/ipipe patches make some changes to the vanilla
>>kernel's printk() mechanism.
>>
>>There are 2 possible modes of printk() being issued from the primary
>>domain.
>>
>>1) asynchronous:
>>
>>all data is written into the protected buffer and the
>>__ipipe_printk_virq virq is risen for the secondary domain. So the
>>data will be printed out when the linux gets control next time.
>>
>>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, and finally, printk() cannot preempt 
__ipipe_flush_printk under normal operation mode (i.e. async mode). AFAICS, 
there's no race here.

>>2) synchronous (IPIPE_SPRINTK_FLAG)
>>
>>in this case, a normal linux vprintk() call is issued. Oops, this one,
>>in turn, calls spin_lock_irqsave(&logbuf_lock, flags); in real-time
>>context and that lock may be already held by a preempted non-rt task
>>on the same CPU.
>>
>>Houston? :o)
>>
> 
> (2) is unacceptable. Losing some data would be acceptable if it is
> caused by too much printk output, but not because of a race condition.
> This should be fixed. I guess a simple FIFO with proper locking should
> be in place. printk would discard data only if there is no space left.
> 
> 
>>>2- Even if it's safe, can it affect the performance of a real time task?
>>>(or can it block under *any* conceivable condition?)
>>
>>It gives some overhead since data must be copied to the buffer and at
>>that time the interrupts are off.
>>Blocked? No, if not taking into account a possible "hang up" with the
>>synchronous mode (ok, as always there is still a hope that I can be
>>wrong ):)
>>
> 
> If you are right, then it's unacceptable. An RT task would be blocked by
> a non-RT task.
> 

Please people, keep things simple and easy: synchronous printk mode is an 
_emergency_ configuration which is of no use under normal runtime conditions. It 
is only there as a desperate debugging help for Adeos/Xeno core development in 
order to force the printk output regardless of the current domain, so it might 
work, but it it doesn't and hits any of the obvious races that the asynchronous 
mode solves, well, nobody is going to complain because it's just a last resort 
bypass in order to get some ultimate traces before the box jumps out of the 
window anyway. IOW, if one keeps using the default and normal async printk mode 
which prevents domain clashes, everything will be fine.

Regarding the overhead induced by a temporary copy of the printk data, if one 
starts having problem with this, then the issue is first caused by spamming the 
kernel log with such amount of information. IOW, cure the real bug, not its 
consequences.

-- 

Philippe.