lkml.org 
[lkml]   [2007]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[PATCH (take 2)] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state
    Andrew Morton pointed out that my changelog was unusable. Sorry!
    Here is a second try with the changelog and kernel version changed.

    Regards,
    Jarek P.

    ------------>(take 2)

    Subject: request_irq() - fix DEBUG_SHIRQ handling

    Mariusz Kozlowski reported lockdep's warning:

    > =================================
    > [ INFO: inconsistent lock state ]
    > 2.6.23-rc2-mm1 #7
    > ---------------------------------
    > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
    > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes:
    > (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too]
    > {in-hardirq-W} state was registered at:
    > [<c0138eeb>] __lock_acquire+0x949/0x11ac
    > [<c01397e7>] lock_acquire+0x99/0xb2
    > [<c0452ff3>] _spin_lock+0x35/0x42
    > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too]
    > [<c0147a5d>] handle_IRQ_event+0x28/0x59
    > [<c01493ca>] handle_level_irq+0xad/0x10b
    > [<c0105a13>] do_IRQ+0x93/0xd0
    > [<c010441e>] common_interrupt+0x2e/0x34
    ...
    > other info that might help us debug this:
    > 1 lock held by ifconfig/5492:
    > #0: (rtnl_mutex){--..}, at: [<c0451778>] mutex_lock+0x1c/0x1f
    >
    > stack backtrace:
    ...
    > [<c0452ff3>] _spin_lock+0x35/0x42
    > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too]
    > [<c01480fd>] free_irq+0x11b/0x146
    > [<de871d59>] rtl8139_close+0x8a/0x14a [8139too]
    > [<c03bde63>] dev_close+0x57/0x74
    ...

    This shows that a driver's irq handler was running both in hard interrupt
    and process contexts with irqs enabled. The latter was done during
    free_irq() call and was possible only with CONFIG_DEBUG_SHIRQ enabled.
    This was fixed by another patch.

    But similar problem is possible with request_irq(): any locks taken from
    irq handler could be vulnerable - especially with soft interrupts. This
    patch fixes it by disabling local interrupts during handler's run. (It
    seems, disabling softirqs should be enough, but it needs more checking
    on possible races or other special cases).

    This patch is recommended to all stable versions since 2.6.21, too.

    Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
    Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>

    ---

    diff -Nurp 2.6.23-rc3-git6-/kernel/irq/manage.c 2.6.23-rc3-git6/kernel/irq/manage.c
    --- 2.6.23-rc3-git6-/kernel/irq/manage.c 2007-08-23 10:11:35.000000000 +0200
    +++ 2.6.23-rc3-git6/kernel/irq/manage.c 2007-08-23 10:16:29.000000000 +0200
    @@ -555,14 +555,11 @@ int request_irq(unsigned int irq, irq_ha
    * We do this before actually registering it, to make sure that
    * a 'real' IRQ doesn't run in parallel with our fake
    */
    - if (irqflags & IRQF_DISABLED) {
    - unsigned long flags;
    + unsigned long flags;

    - local_irq_save(flags);
    - handler(irq, dev_id);
    - local_irq_restore(flags);
    - } else
    - handler(irq, dev_id);
    + local_irq_save(flags);
    + handler(irq, dev_id);
    + local_irq_restore(flags);
    }
    #endif

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2007-08-23 10:47    [W:0.065 / U:31.516 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site