Re: [RFC][PATCH] IRQ: Fix oneshot irq race between irq_finalize_oneshot and handle_level_irq
From: Valdis . Kletnieks
Date: Tue Mar 09 2010 - 11:59:38 EST
On Tue, 09 Mar 2010 08:58:11 +0100, Thomas Gleixner said:
> On Tue, 9 Mar 2010, Lars-Peter Clausen wrote:
>
> > If the kernel has been compiled with preemtion support and handle_level_irq is
> > called from process context for a oneshot irq there is a race between
> > irq_finalize_oneshot and handle_level_irq which results in the irq not being
> > unmasked after its handlers have been run.
> >
> > irq_finalize_oneshot is expected to unmask the irq after the threaded irq
> > handler has been run. It only does so if IRQ_MASKED is set for the irqs status.
> > IRQ_MASKED gets set in the lower part of handle_level_irq after handle_IRQ_event
> > has been called.
> > handle_IRQ_event will wakeup the oneshot irqs threaded handler and if the
> > kernel has been build with preemption there is a chance that the threaded irq
> > handler will finish before execution is returned to handle_level_irq.
> > As a result irq_finalize_oneshot will not unmask the irq and handle_level_irq
> > will set the IRQ_MASKED flag. Thus the irq will stay masked and stalls.
> >
> > In case of an race the call-graph would look like this:
> > handle_level_irq
> > |- mask_ack_irq
> > |- handle_IRQ_event
> > |- wake_up_process
> > |- irq_thread
> > |- action->thread_fn
> > |- irq_finalize_oneshot # Does not unmask the irq
> > |- # Set IRQ_MASKED status flag
>
> Errm, a thread _CANNOT_ preempt a hard interrupt handler.
What stops the thread from concurrently running on another CPU and racing
that way? I'm an idiot, use small words. :)
Attachment:
pgp00000.pgp
Description: PGP signature