[lkml]   [2010]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] IRQ: Fix oneshot irq race between irq_finalize_oneshot and handle_level_irq
    Hash: SHA1

    Thomas Gleixner wrote:
    > On Tue, 9 Mar 2010, 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
    >>>> 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
    >>>> 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. :)
    Yes, sorry for bothering you with that. I actually had the symptoms
    described on a non SMP system. The irq in question was part of a
    longer irq chain and I though that it might be detached from the
    hardirq context somewhere along the chain.
    After your comment I reread some parts and it turned out that
    irq_enter()/irq_exit() was missing around the first level irq handler.

    - - Lars
    > Will have a look after dinner.
    > Thanks,
    > tglx

    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----

     \ /
      Last update: 2010-03-10 00:03    [W:0.025 / U:32.728 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site