Re: Race condition in interrupt handling

Hi,

What happens is that the interrupt is still masked even after 
intctrl_t::unmask() is called. It seems to me that the following 
interleaving is happening:

A thread is finished handling an interrupt and try to unmask the irq by 
calling intctrl_t::unmask():
      if (redir[irq].entry.is_edge_triggered())
      {
      if (redir[irq].pending)
      {
          redir[irq].pending = false;

/**
   * (1) INTERRUPT COMES HERE
   **/
          return true; // leave IRQ masked, since there was another pending
      }

An interrupt comes in at (1) and executes the intctrl_t::handle_irq()

      bool deliver = true;

      // edge triggered IRQs are marked as pending if masked
      if ( redir[irq].entry.is_edge_triggered() &&
       redir[irq].entry.x.mask )
...
      redir[irq].pending = true;
      deliver = false;
      }

Which resets the pending to true without delivering the interrupt.

Haohui
On 04/13/2010 02:20 AM, Jan Stoess wrote:
>
> Hi Haohui,
>
> There's no line 423 in api/v4/interrupt.cc in the current HG repo, I 
> am assuming you're referring to line 86.
>
> Anyway,  thanks for the patch. Before we commit the fix, can you 
> elaborate a little bit more on the race condition you're hitting? In 
> particular, I thought APIC redir entries are modified by one dedicated 
> CPU only -- the CPU the IRQ is routed to, so races should occur only 
> during IRQ migration. While I can imagine that there might be a race 
> at times, I am also wondering if we can get away without locking every 
> modification of a redirection entry.
>
> Thanks!
>
> -Jan
>
> --
>
> Jan Stoess
>
> KIT/UKa System Architecture Group
>
> Phone: +49 (721) 608-4056
>
> Fax: +49 (721) 608-7664
>
> http://os.ibds.kit.edu/stoess
>