Philippe Gerum wrote:
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.
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.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
