14 Oct, 2015

1 commit

  • commit 9d67dc5da59d63f746aad8f6ec4fbb86d6486f76 upstream.

    A cleanup of the omap gpio driver introduced a use of the
    Handle_bad_irq() function in a device driver that can be
    a loadable module.

    This broke the ARM allmodconfig build:

    ERROR: "handle_bad_irq" [drivers/gpio/gpio-omap.ko] undefined!

    This patch exports the handle_bad_irq symbol in order to
    allow the use in modules.

    Signed-off-by: Arnd Bergmann
    Cc: Grygorii Strashko
    Cc: Santosh Shilimkar
    Cc: Linus Walleij
    Cc: Austin Schuh
    Cc: Tony Lindgren
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/5847725.4IBopItaOr@wuerfel
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Dan Murphy

    Arnd Bergmann
     

22 Mar, 2014

1 commit

  • This will allow to use the dummy IRQ handler no_action() from drivers
    compiled as module. Drivers which use ARM FIQ interrupts can use this
    to request the interrupt via the normal request_irq() mechanism w/o
    having to copy the dummy handler to their own code.

    Signed-off-by: Alexander Shiyan
    Link: http://lkml.kernel.org/r/1395476431-16070-1-git-send-email-shc_work@mail.ru
    Signed-off-by: Thomas Gleixner

    Alexander Shiyan
     

20 Feb, 2014

1 commit

  • In course of the sdhci/sdio discussion with Russell about killing the
    sdio kthread hackery we discovered the need to be able to wake an
    interrupt thread from software.

    The rationale for this is, that sdio hardware can lack proper
    interrupt support for certain features. So the driver needs to poll
    the status registers, but at the same time it needs to be woken up by
    an hardware interrupt.

    To be able to get rid of the home brewn kthread construct of sdio we
    need a way to wake an irq thread independent of an actual hardware
    interrupt.

    Provide an irq_wake_thread() function which wakes up the thread which
    is associated to a given dev_id. This allows sdio to invoke the irq
    thread from the hardware irq handler via the IRQ_WAKE_THREAD return
    value and provides a possibility to wake it via a timer for the
    polling scenarios. That allows to simplify the sdio logic
    significantly.

    Signed-off-by: Thomas Gleixner
    Cc: Russell King
    Cc: Chris Ball
    Acked-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20140215003823.772565780@linutronix.de

    Thomas Gleixner
     

15 Jul, 2012

1 commit

  • We've been moving away from add_interrupt_randomness() for various
    reasons: it's too expensive to do on every interrupt, and flooding the
    CPU with interrupts could theoretically cause bogus floods of entropy
    from a somewhat externally controllable source.

    This solves both problems by limiting the actual randomness addition
    to just once a second or after 64 interrupts, whicever comes first.
    During that time, the interrupt cycle data is buffered up in a per-cpu
    pool. Also, we make sure the the nonblocking pool used by urandom is
    initialized before we start feeding the normal input pool. This
    assures that /dev/urandom is returning unpredictable data as soon as
    possible.

    (Based on an original patch by Linus, but significantly modified by
    tytso.)

    Tested-by: Eric Wustrow
    Reported-by: Eric Wustrow
    Reported-by: Nadia Heninger
    Reported-by: Zakir Durumeric
    Reported-by: J. Alex Halderman .
    Signed-off-by: Linus Torvalds
    Signed-off-by: "Theodore Ts'o"
    Cc: stable@vger.kernel.org

    Theodore Ts'o
     

29 Mar, 2012

1 commit

  • exit_irq_thread() clears IRQTF_RUNTHREAD flag and drops the thread's bit in
    desc->threads_oneshot then. The bit must not be set again in between and it
    does not, since irq_wake_thread() sees PF_EXITING flag first and returns.

    Due to above the order or checking PF_EXITING and IRQTF_RUNTHREAD flags in
    irq_wake_thread() is important. This change just makes it more visible in the
    source code.

    Signed-off-by: Alexander Gordeev
    Link: http://lkml.kernel.org/r/20120321162212.GO24806@dhcp-26-207.brq.redhat.com
    Signed-off-by: Thomas Gleixner

    Alexander Gordeev
     

14 Mar, 2012

1 commit

  • The current implementation does not always flush the threaded handler
    when disabling the irq. In case the irq handler was called, but the
    threaded handler hasn't started running yet, the interrupt will be
    flagged as pending, and the handler will not run. This implementation
    has some issues:

    First, if the interrupt is a wake source and flagged as pending, the
    system will not be able to suspend.

    Second, when quickly disabling and re-enabling the irq, the threaded
    handler might continue to run after the irq is re-enabled without the
    irq handler being called first. This might be an unexpected behavior.

    In addition, it might be counter-intuitive that the threaded handler
    will not be called even though the irq handler was called and returned
    IRQ_WAKE_THREAD.

    Fix this by always waiting for the threaded handler to complete in
    synchronize_irq().

    [ tglx: Massaged comments, added WARN_ONs and the missing
    IRQTF_RUNTHREAD check in exit_irq_thread() ]

    Signed-off-by: Ido Yariv
    Link: http://lkml.kernel.org/r/1322843052-7166-1-git-send-email-ido@wizery.com
    Signed-off-by: Thomas Gleixner

    Ido Yariv
     

10 Mar, 2012

1 commit

  • Currently IRQTF_DIED flag is set when a IRQ thread handler calls do_exit()
    But also PF_EXITING per process flag gets set when a thread exits. This
    fix eliminates the duplicate by using PF_EXITING flag.

    Also, there is a race condition in exit_irq_thread(). In case a thread's
    bit is cleared in desc->threads_oneshot (and the IRQ line gets unmasked),
    but before IRQTF_DIED flag is set, a new interrupt might come in and set
    just cleared bit again, this time forever. This fix throws IRQTF_DIED flag
    away, eliminating the race as a result.

    [ tglx: Test THREAD_EXITING first as suggested by Oleg ]

    Reported-by: Oleg Nesterov
    Signed-off-by: Alexander Gordeev
    Link: http://lkml.kernel.org/r/20120309135958.GD2114@dhcp-26-207.brq.redhat.com
    Signed-off-by: Thomas Gleixner

    Alexander Gordeev
     

03 Jun, 2011

1 commit

  • The detection of spurios interrupts is currently limited to first level
    handler. In force-threaded mode we never notice if the threaded irq does
    not feel responsible.
    This patch catches the return value of the threaded handler and forwards
    it to the spurious detector. If the primary handler returns only
    IRQ_WAKE_THREAD then the spourious detector ignores it because it gets
    called again from the threaded handler.

    [ tglx: Report the erroneous return value early and bail out ]

    Signed-off-by: Sebastian Andrzej Siewior
    Link: http://lkml.kernel.org/r/1306824972-27067-2-git-send-email-sebastian@breakpoint.cc
    Signed-off-by: Thomas Gleixner

    Sebastian Andrzej Siewior
     

29 Mar, 2011

1 commit


28 Mar, 2011

2 commits


26 Feb, 2011

2 commits

  • For level type interrupts we need to track how many threads are on
    flight to avoid useless interrupt storms when not all thread handlers
    have finished yet. Keep track of the woken threads and only unmask
    when there are no more threads in flight.

    Yes, I'm lazy and using a bitfield. But not only because I'm lazy, the
    main reason is that it's way simpler than using a refcount. A refcount
    based solution would need to keep track of various things like
    crashing the irq thread, spurious interrupts coming in,
    disables/enables, free_irq() and some more. The bitfield keeps the
    tracking simple and makes things just work. It's also nicely confined
    to the thread code pathes and does not require additional checks all
    over the place.

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    LKML-Reference:

    Thomas Gleixner
     
  • The WARN_ON_ONCE in handle_percpu_event() which emits a warning when
    an action handler returns with interrupts enabled is not really
    useful. It does not reveal the interrupt number and handler function
    which caused it. Make it WARN_ONCE() and add the information.

    Reported-by: Tony Luck
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

22 Feb, 2011

1 commit

  • note_interrupt wants to be called with the combined result of all
    handlers called, not with the last one. If it's a shared interrupt
    then the last handler might return IRQ_NONE often enough to trigger
    the spurious dectector which turns off a perfectly fine working
    interrupt line. Bug was introduced in commit 1277a532(genirq: Simplify
    handle_irq_event()).

    Yes, I really messed up there. First the variable ret should not have
    been named differently to avoid similarity with retval. Second it
    should have been declared in the do {} loop.

    Rename it to res and move it into the do {} loop and vanish under a
    huge brown paperbag.

    Reported-bisected-tested-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

19 Feb, 2011

6 commits


21 Jan, 2011

1 commit

  • All architectures are finally converted. Remove the cruft.

    Signed-off-by: Thomas Gleixner
    Cc: Richard Henderson
    Cc: Mike Frysinger
    Cc: David Howells
    Cc: Tony Luck
    Cc: Greg Ungerer
    Cc: Michal Simek
    Acked-by: David Howells
    Cc: Kyle McMartin
    Acked-by: Benjamin Herrenschmidt
    Cc: Chen Liqin
    Cc: "David S. Miller"
    Cc: Chris Metcalf
    Cc: Jeff Dike

    Thomas Gleixner
     

12 Oct, 2010

1 commit

  • kernel/irq/handle.c has become a dumpground for random code in random
    order. Split out the irq descriptor management and the dummy irq_chip
    implementation into separate files. Cleanup the include maze while at
    it.

    No code change.

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Ingo Molnar

    Thomas Gleixner
     

04 Oct, 2010

10 commits


13 Apr, 2010

1 commit

  • Running interrupt handlers with interrupts enabled can cause stack
    overflows. That has been observed with multiqueue NICs delivering all
    their interrupts to a single core. We might band aid that somehow by
    checking the interrupt stacks, but the real safe fix is to run the irq
    handlers with interrupts disabled.

    Drivers for whacky hardware still can reenable them in the handler
    itself, if the need arises. (They do already due to lockdep)

    The risk of doing this is rather low:

    - lockdep already enforces this
    - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
    - time keeping is not longer sensitive to the timer interrupt being delayed

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Alan Cox
    Cc: Andi Kleen
    Cc: David Miller
    Cc: Greg Kroah-Hartman
    Cc: Arnaldo Carvalho de Melo
    Cc: Linus Torvalds
    LKML-Reference:

    Ingo Molnar
     

18 Feb, 2010

3 commits


15 Dec, 2009

1 commit


12 Oct, 2009

1 commit


29 Aug, 2009

1 commit


12 Jun, 2009

1 commit

  • Ingo had

    [ 0.000000] ------------[ cut here ]------------
    [ 0.000000] WARNING: at mm/bootmem.c:537 alloc_arch_preferred_bootmem+0x2b/0x71()
    [ 0.000000] Hardware name: System Product Name
    [ 0.000000] Modules linked in:
    [ 0.000000] Pid: 0, comm: swapper Tainted: G W 2.6.30-tip-03087-g0bb2618-dirty #52506
    [ 0.000000] Call Trace:
    [ 0.000000] [] warn_slowpath_common+0x60/0x90
    [ 0.000000] [] warn_slowpath_null+0xd/0x10
    [ 0.000000] [] alloc_arch_preferred_bootmem+0x2b/0x71
    [ 0.000000] [] ___alloc_bootmem_nopanic+0x2b/0x9a
    [ 0.000000] [] ? lock_release+0xac/0xb2
    [ 0.000000] [] ___alloc_bootmem+0xe/0x2d
    [ 0.000000] [] __alloc_bootmem+0xa/0xc
    [ 0.000000] [] alloc_bootmem_cpumask_var+0x21/0x26
    [ 0.000000] [] early_irq_init+0x15/0x10d
    [ 0.000000] [] start_kernel+0x167/0x326
    [ 0.000000] [] __init_begin+0x6b/0x70
    [ 0.000000] ---[ end trace 4eaa2a86a8e2da23 ]---
    [ 0.000000] NR_IRQS:2304 nr_irqs:424
    [ 0.000000] CPU 0 irqstacks, hard=821e6000 soft=821e7000

    we need to update init_irq_default_affinity

    Signed-off-by: Yinghai Lu
    Signed-off-by: Pekka Enberg

    Yinghai Lu