Re: Race condition in interrupt handling

The interrupt is re-enabled by after local_apic.EOI() is called, which 
means interrupt is enabled in irq_thread(). Therefore, irq_thread() can 
be preempted by an interrupt at that time.

I enabled the trace statement at api/v4/interrupt.cc:172, what I can saw 
during debugging is something like:

IRQ12 (curr=IRQ_12)

I do enable SMP in the kernel, but I don't think I enable any migration 
right now, so everything should be running on CPU 0.

Haohui


On 04/13/2010 08:02 AM, Jan Stoess wrote:
>
> This seems fishy to me. intctrl_t::unmask() should only be called by 
> irq_thread, which resides on the CPU the IRQ is routed to. Since it is 
> in the kernel, how can the new IRQ be delivered to the CPU at the 
> point you're referring to with (1) INTERRUPT COMES HERE? Again, does 
> this happen during IRQ migration? Maybe you can use the tracebuffer 
> (potentially even inserting some tracing statements at the critical 
> points yourself, e.g. via TRACE_IRQ_DETAILS() and tp_irq_mask, latter 
> of which you can set in the KDB menu, in the tracebuffer submenu "y") 
> and dump a corresponding trace log to this list?
>
> Thanks again,
>
> -Jan
>
> --
>
> Jan Stoess
>
> KIT/UKa System Architecture Group
>
> Phone: +49 (721) 608-4056
>
> Fax: +49 (721) 608-7664
>
> http://os.ibds.kit.edu/stoess
>