18 Jun, 2016

1 commit

  • This adds a software irq handler for controllers that multiplex
    interrupts from multiple devices, but don't know which device generated
    the interrupt. For these devices, the irq handler that demuxes must
    check every action for every software irq using the same h/w irq in order
    to find out which device generated the interrupt. This will inevitably
    trigger spurious interrupt detection if we are noting the irq.

    The new irq handler does not track the handling for spurious interrupt
    detection. An irq that uses this also won't get stats tracked since it
    didn't generate the interrupt, nor added to randomness since they are
    not random.

    Signed-off-by: Keith Busch
    Cc: Bjorn Helgaas
    Cc: linux-pci@vger.kernel.org
    Cc: Jon Derrick
    Link: http://lkml.kernel.org/r/1466200821-29159-1-git-send-email-keith.busch@intel.com
    Signed-off-by: Thomas Gleixner

    Keith Busch
     

15 Feb, 2016

1 commit

  • The irq code browses the list of actions differently to inspect the element
    one by one. Even if it is not a problem, for the sake of consistent code,
    provide a macro similar to for_each_irq_desc in order to have the same loop to
    go through the actions list and use it in the code.

    [ tglx: Renamed the macro ]

    Signed-off-by: Daniel Lezcano
    Link: http://lkml.kernel.org/r/1452765253-31148-1-git-send-email-daniel.lezcano@linaro.org
    Signed-off-by: Thomas Gleixner

    Daniel Lezcano
     

15 Jan, 2016

1 commit

  • commit 71f64340fc0e changed the handling of irq_desc->action from

    CPU 0 CPU 1
    free_irq() lock(desc)
    lock(desc) handle_edge_irq()
    if (desc->action) {
    handle_irq_event()
    action = desc->action
    unlock(desc)
    desc->action = NULL handle_irq_event_percpu(desc, action)
    action->xxx
    to

    CPU 0 CPU 1
    free_irq() lock(desc)
    lock(desc) handle_edge_irq()
    if (desc->action) {
    handle_irq_event()
    unlock(desc)
    desc->action = NULL handle_irq_event_percpu(desc, action)
    action = desc->action
    action->xxx

    So if free_irq manages to set the action to NULL between the unlock and before
    the readout, we happily dereference a null pointer.

    We could simply revert 71f64340fc0e, but we want to preserve the better code
    generation. A simple solution is to change the action loop from a do {} while
    to a while {} loop.

    This is safe because we either see a valid desc->action or NULL. If the action
    is about to be removed it is still valid as free_irq() is blocked on
    synchronize_irq().

    CPU 0 CPU 1
    free_irq() lock(desc)
    lock(desc) handle_edge_irq()
    handle_irq_event(desc)
    set(INPROGRESS)
    unlock(desc)
    handle_irq_event_percpu(desc)
    action = desc->action
    desc->action = NULL while (action) {
    action->xxx
    ...
    action = action->next;
    sychronize_irq()
    while(INPROGRESS); lock(desc)
    clr(INPROGRESS)
    free(action)

    That's basically the same mechanism as we have for shared
    interrupts. action->next can become NULL while handle_irq_event_percpu()
    runs. Either it sees the action or NULL. It does not matter, because action
    itself cannot go away before the interrupt in progress flag has been cleared.

    Fixes: commit 71f64340fc0e "genirq: Remove the second parameter from handle_irq_event_percpu()"
    Reported-by: zyjzyj2000@gmail.com
    Signed-off-by: Thomas Gleixner
    Cc: Huang Shijie
    Cc: Jiang Liu
    Cc: Peter Zijlstra
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1601131224190.3575@nanos

    Thomas Gleixner
     

14 Oct, 2015

1 commit


09 Oct, 2015

2 commits

  • A recent cleanup removed the 'irq' parameter from many functions, but
    left the documentation for this in place for at least one function.

    This removes it.

    Fixes: bd0b9ac405e1 ("genirq: Remove irq argument from irq flow handlers")
    Reported-by: kbuild test robot
    Signed-off-by: Arnd Bergmann
    Cc: Grygorii Strashko
    Cc: Tony Lindgren
    Cc: Linus Walleij
    Cc: kbuild-all@01.org
    Cc: Austin Schuh
    Cc: Santosh Shilimkar
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/5400000.cD19rmgWjV@wuerfel
    Signed-off-by: Thomas Gleixner

    Arnd Bergmann
     
  • 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

    Arnd Bergmann
     

22 Sep, 2015

1 commit

  • Actually, we always use the first irq action of the @desc->action
    chain, so remove the second parameter from handle_irq_event_percpu()
    which makes the code more tidy.

    Signed-off-by: Huang Shijie
    Reviewed-by: Jiang Liu
    Cc: peterz@infradead.org
    Cc: marc.zyngier@arm.com
    Link: http://lkml.kernel.org/r/1441160695-19809-1-git-send-email-shijie.huang@arm.com
    Signed-off-by: Thomas Gleixner

    Huang Shijie
     

16 Sep, 2015

1 commit

  • Most interrupt flow handlers do not use the irq argument. Those few
    which use it can retrieve the irq number from the irq descriptor.

    Remove the argument.

    Search and replace was done with coccinelle and some extra helper
    scripts around it. Thanks to Julia for her help!

    Signed-off-by: Thomas Gleixner
    Cc: Julia Lawall
    Cc: Jiang Liu

    Thomas Gleixner
     

12 Jul, 2015

2 commits

  • Only required for the slow path. Retrieve it from irq descriptor if
    necessary.

    [ tglx: Split out from combo patch. Left [try_]misrouted_irq()
    untouched as there is no win in the slow path ]

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Bjorn Helgaas
    Cc: Benjamin Herrenschmidt
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: Jason Cooper
    Cc: Kevin Cernekee
    Cc: Arnd Bergmann
    Link: http://lkml.kernel.org/r/1433391238-19471-19-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     
  • The first parameter 'irq' is never used by
    kstat_incr_irqs_this_cpu(). Remove it.

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Bjorn Helgaas
    Cc: Benjamin Herrenschmidt
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Link: http://lkml.kernel.org/r/1433391238-19471-16-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

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

9 commits