lkml.org 
[lkml]   [2010]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] IRQ: Fix oneshot irq race between irq_finalize_oneshot and handle_level_irq
    On Tue, 9 Mar 2010, Valdis.Kletnieks@vt.edu wrote:
    > 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. :)

    Right it's a valid SMP problem, but I got confused by the lengthy
    explanation of a thread preempting an hard interrupt handler. :)

    Will have a look after dinner.

    Thanks,

    tglx



    \
     
     \ /
      Last update: 2010-03-09 19:13    [W:0.030 / U:61.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site