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?

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

Reply via email to