Re: Race condition in interrupt handling

What it seems to me is that the CPU is running irq_thread(), and the 
hardware interrupt comes in, so that the CPU executes the interrupt 
handler (which is intctrl_t::handle_irq()) and causes this problem. The 
whole thing happens in kernel and it is irrelevant to the delivery to 
the user level handler.

handle_irq() {
...
...
local_apic.EOI();
// Interrupt re-enabled here
...
handle_interrupt();
}

handle_interrupt might switch to irq_thread(), but the hardware 
interrupt is enabled by this point. So I guess the funky IRQ12 
(curr=IRQ_12) could happen.


Haohui

On 04/13/2010 08:51 AM, Jan Stoess wrote:
>
> But the current kernel runs (should, at least) non-preemptive and 
> irq_thread runs in kernel mode, so any pending IRQ shouldn't be 
> delivered until the next return to user.
>
> Am I missing something??
>
> -Jan
>
> --
>
> Jan Stoess
>
> KIT/UKa System Architecture Group
>
> Phone: +49 (721) 608-4056
>
> Fax: +49 (721) 608-7664
>
> http://os.ibds.kit.edu/stoess
>
> *From:* Mai, Haohui [mailto:[email protected]]
> *Sent:* Tuesday, April 13, 2010 3:34 PM
> *To:* Jan Stoess
> *Cc:* [email protected]
> *Subject:* 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
>