Dmitry Adamushko wrote:
Philippe Gerum <[EMAIL PROTECTED]> 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.
---
Best regards,
Dmitry
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
