1. 10 May, 2019 1 commit
  2. 17 Apr, 2019 2 commits
    • Kefeng Wang's avatar
      genirq: Initialize request_mutex if CONFIG_SPARSE_IRQ=n · 82e1fb4d
      Kefeng Wang authored
      commit e8458e7afa855317b14915d7b86ab3caceea7eb6 upstream.
      When CONFIG_SPARSE_IRQ is disable, the request_mutex in struct irq_desc
      is not initialized which causes malfunction.
      Fixes: 9114014c ("genirq: Add mutex to irq desc to serialize request/free_irq()")
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190404074512.145533-1-wangkefeng.wang@huawei.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Stephen Boyd's avatar
      genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() · 3559f73e
      Stephen Boyd authored
      commit 325aa19598e410672175ed50982f902d4e3f31c5 upstream.
      If a child irqchip calls irq_chip_set_wake_parent() but its parent irqchip
      has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned.
      This is inconsistent behaviour vs. set_irq_wake_real() which returns 0 when
      the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to
      walk the chain of parents and set irq wake on any chips that don't have the
      flag set either. If the intent is to call the .irq_set_wake() callback of
      the parent irqchip, then we expect irqchip implementations to omit the
      IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function that
      calls irq_chip_set_wake_parent().
      The problem has been observed on a Qualcomm sdm845 device where set wake
      fails on any GPIO interrupts after applying work in progress wakeup irq
      patches to the GPIO driver. The chain of chips looks like this:
      The GPIO controllers parent is the QCOM PDC irqchip which in turn has ARM
      GIC as parent.  The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE flag
      set, and so does the grandparent ARM GIC.
      The GPIO driver doesn't know if the parent needs to set wake or not, so it
      unconditionally calls irq_chip_set_wake_parent() causing this function to
      return a failure because the parent irqchip (PDC) doesn't have the
      .irq_set_wake() callback set. Returning 0 instead makes everything work and
      irqs from the GPIO controller can be configured for wakeup.
      Make it consistent by returning 0 (success) from irq_chip_set_wake_parent()
      when a parent chip has IRQCHIP_SKIP_SET_WAKE set.
      [ tglx: Massaged changelog ]
      Fixes: 08b55e2a ("genirq: Add irqchip_set_wake_parent")
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-gpio@vger.kernel.org
      Cc: Lina Iyer <ilina@codeaurora.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 05 Apr, 2019 1 commit
    • Thomas Gleixner's avatar
      genirq: Avoid summation loops for /proc/stat · e4688147
      Thomas Gleixner authored
      [ Upstream commit 1136b0728969901a091f0471968b2b76ed14d9ad ]
      Waiman reported that on large systems with a large amount of interrupts the
      readout of /proc/stat takes a long time to sum up the interrupt
      statistics. In principle this is not a problem. but for unknown reasons
      some enterprise quality software reads /proc/stat with a high frequency.
      The reason for this is that interrupt statistics are accounted per cpu. So
      the /proc/stat logic has to sum up the interrupt stats for each interrupt.
      This can be largely avoided for interrupts which are not marked as
      'PER_CPU' interrupts by simply adding a per interrupt summation counter
      which is incremented along with the per interrupt per cpu counter.
      The PER_CPU interrupts need to avoid that and use only per cpu accounting
      because they share the interrupt number and the interrupt descriptor and
      concurrent updates would conflict or require unwanted synchronization.
      Reported-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Daniel Colascione <dancol@google.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Link: https://lkml.kernel.org/r/20190208135020.925487496@linutronix.de
      v2: Undo the unintentional layout change of struct irq_desc.
       include/linux/irqdesc.h |    1 +
       kernel/irq/chip.c       |   12 ++++++++++--
       kernel/irq/internals.h  |    8 +++++++-
       kernel/irq/irqdesc.c    |    7 ++++++-
       4 files changed, 24 insertions(+), 4 deletions(-)
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  4. 05 Mar, 2019 1 commit
  5. 13 Jan, 2019 1 commit
  6. 13 Nov, 2018 1 commit
    • Lukas Wunner's avatar
      genirq: Fix race on spurious interrupt detection · e6b8a4d7
      Lukas Wunner authored
      commit 746a923b863a1065ef77324e1e43f19b1a3eab5c upstream.
      Commit 1e77d0a1 ("genirq: Sanitize spurious interrupt detection of
      threaded irqs") made detection of spurious interrupts work for threaded
      handlers by:
      a) incrementing a counter every time the thread returns IRQ_HANDLED, and
      b) checking whether that counter has increased every time the thread is
      However for oneshot interrupts, the commit unmasks the interrupt before
      incrementing the counter.  If another interrupt occurs right after
      unmasking but before the counter is incremented, that interrupt is
      incorrectly considered spurious:
       |  irq_thread()
       |    irq_thread_fn()
       |      action->thread_fn()
       |      irq_finalize_oneshot()
       |        unmask_threaded_irq()            /* interrupt is unmasked */
       |                  /* interrupt fires, incorrectly deemed spurious */
       |    atomic_inc(&desc->threads_handled); /* counter is incremented */
      This is observed with a hi3110 CAN controller receiving data at high volume
      (from a separate machine sending with "cangen -g 0 -i -x"): The controller
      signals a huge number of interrupts (hundreds of millions per day) and
      every second there are about a dozen which are deemed spurious.
      In theory with high CPU load and the presence of higher priority tasks, the
      number of incorrectly detected spurious interrupts might increase beyond
      the 99,900 threshold and cause disablement of the interrupt.
      In practice it just increments the spurious interrupt count. But that can
      cause people to waste time investigating it over and over.
      Fix it by moving the accounting before the invocation of
      [ tglx: Folded change log update ]
      Fixes: 1e77d0a1 ("genirq: Sanitize spurious interrupt detection of threaded irqs")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mathias Duckeck <m.duckeck@kunbus.de>
      Cc: Akshay Bhat <akshay.bhat@timesys.com>
      Cc: Casey Fitzpatrick <casey.fitzpatrick@timesys.com>
      Cc: stable@vger.kernel.org # v3.16+
      Link: https://lkml.kernel.org/r/1dfd8bbd16163940648045495e3e9698e63b50ad.1539867047.git.lukas@wunner.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 23 Sep, 2018 2 commits
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      genirq: add generic I-pipe core · d47c5520
      Philippe Gerum authored
      This commit provides the arch-independent bits for implementing the
      interrupt pipeline core, a lightweight layer introducing a separate,
      high-priority execution stage for handling all IRQs in pseudo-NMI
      mode, which cannot be delayed by the regular kernel code. See
      Documentation/ipipe.rst for details about interrupt pipelining.
      Architectures which support interrupt pipelining should select
      HAVE_IPIPE_SUPPORT, along with implementing the required arch-specific
      code. In such a case, CONFIG_IPIPE becomes available to the user via
      the Kconfig interface for enabling the feature.
  8. 09 Aug, 2018 1 commit
    • Thomas Gleixner's avatar
      genirq: Make force irq threading setup more robust · a6d9dacf
      Thomas Gleixner authored
      commit d1f0301b upstream.
      The support of force threading interrupts which are set up with both a
      primary and a threaded handler wreckaged the setup of regular requested
      threaded interrupts (primary handler == NULL).
      The reason is that it does not check whether the primary handler is set to
      the default handler which wakes the handler thread. Instead it replaces the
      thread handler with the primary handler as it would do with force threaded
      interrupts which have been requested via request_irq(). So both the primary
      and the thread handler become the same which then triggers the warnon that
      the thread handler tries to wakeup a not configured secondary thread.
      Fortunately this only happens when the driver omits the IRQF_ONESHOT flag
      when requesting the threaded interrupt, which is normaly caught by the
      sanity checks when force irq threading is disabled.
      Fix it by skipping the force threading setup when a regular threaded
      interrupt is requested. As a consequence the interrupt request which lacks
      the IRQ_ONESHOT flag is rejected correctly instead of silently wreckaging
      Fixes: 2a1d3ab8 ("genirq: Handle force threading of irqs with primary and thread handler")
      Reported-by: default avatarKurt Kanzenbach <kurt.kanzenbach@linutronix.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarKurt Kanzenbach <kurt.kanzenbach@linutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 17 Jul, 2018 1 commit
  10. 11 Jul, 2018 1 commit
  11. 03 Mar, 2018 1 commit
  12. 30 Nov, 2017 1 commit
    • Marc Zyngier's avatar
      genirq: Track whether the trigger type has been set · c01dd3ad
      Marc Zyngier authored
      commit 4f8413a3 upstream.
      When requesting a shared interrupt, we assume that the firmware
      support code (DT or ACPI) has called irqd_set_trigger_type
      already, so that we can retrieve it and check that the requester
      is being reasonnable.
      Unfortunately, we still have non-DT, non-ACPI systems around,
      and these guys won't call irqd_set_trigger_type before requesting
      the interrupt. The consequence is that we fail the request that
      would have worked before.
      We can either chase all these use cases (boring), or address it
      in core code (easier). Let's have a per-irq_desc flag that
      indicates whether irqd_set_trigger_type has been called, and
      let's just check it when checking for a shared interrupt.
      If it hasn't been set, just take whatever the interrupt
      requester asks.
      Fixes: 382bd4de ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
      Reported-and-tested-by: default avatarPetr Cvek <petrcvekcz@gmail.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
      All documentation files were explicitly excluded.
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
         For non */uapi/* files that summary was:
         SPDX license identifier                            # files
         GPL-2.0                                              11139
         and resulted in the first patch in this series.
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                        930
         and resulted in the second patch in this series.
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
         and that resulted in the third patch in this series.
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. 13 Oct, 2017 2 commits
    • Doug Berger's avatar
      genirq: generic chip: remove irq_gc_mask_disable_reg_and_ack() · 0d08af35
      Doug Berger authored
      Any usage of the irq_gc_mask_disable_reg_and_ack() function has
      been replaced with the desired functionality.
      The incorrect and ambiguously named function is removed here to
      prevent accidental misuse.
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Doug Berger's avatar
      genirq: generic chip: Add irq_gc_mask_disable_and_ack_set() · 20608924
      Doug Berger authored
      The irq_gc_mask_disable_reg_and_ack() function name implies that it
      provides the combined functions of irq_gc_mask_disable_reg() and
      irq_gc_ack().  However, the implementation does not actually do
      that since it writes the mask instead of the disable register. It
      also does not maintain the mask cache which makes it inappropriate
      to use with other masking functions.
      In addition, commit 659fb32d ("genirq: replace irq_gc_ack() with
      {set,clr}_bit variants (fwd)") effectively renamed irq_gc_ack() to
      irq_gc_ack_set_bit() so this function probably should have also been
      renamed at that time.
      The generic chip code currently provides three functions for use
      with the irq_mask member of the irq_chip structure and two functions
      for use with the irq_ack member of the irq_chip structure. These
      functions could be combined into six functions for use with the
      irq_mask_ack member of the irq_chip structure.  However, since only
      one of the combinations is currently used, only the function
      irq_gc_mask_disable_and_ack_set() is added by this commit.
      The '_reg' and '_bit' portions of the base function name were left
      out of the new combined function name in an attempt to keep the
      function name length manageable with the 80 character source code
      line length while still allowing the distinct aspects of each
      combination to be captured by the name.
      If other combinations are desired in the future please add them to
      the irq generic chip library at that time.
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  15. 09 Oct, 2017 3 commits
    • Thomas Gleixner's avatar
      genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs · e43b3b58
      Thomas Gleixner authored
      Managed interrupts can end up in a stale state on CPU hotplug. If the
      interrupt is not targeting a single CPU, i.e. the affinity mask spawns
      multiple CPUs then the following can happen:
      After boot:
      dstate:   0x01601200
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  0
      After offlining CPU 31 - 24
      dstate:   0x01a31000
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  0
      Now CPU 25 gets onlined again, so it should get the effective interrupt
      affinity for this interruopt, but due to the x86 interrupt affinity setter
      restrictions this ends up after restarting the interrupt with:
      dstate:   0x01601300
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  24-31
      So the interrupt is still affine to CPU 24, which was the last CPU to go
      offline of that affinity set and the move to an online CPU within 24-31,
      in this case 25, is pending. This mechanism is x86/ia64 specific as those
      architectures cannot move interrupts from thread context and do this when
      an interrupt is actually handled. So the move is set to pending.
      Whats worse is that offlining CPU 25 again results in:
      dstate:   0x01601300
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  24-31
      This means the interrupt has not been shut down, because the outgoing CPU
      is not in the effective affinity mask, but of course nothing notices that
      the effective affinity mask is pointing at an offline CPU.
      In the case of restarting a managed interrupt the move restriction does not
      apply, so the affinity setting can be made unconditional. This needs to be
      done _before_ the interrupt is started up as otherwise the condition for
      moving it from thread context would not longer be fulfilled.
      With that change applied onlining CPU 25 after offlining 31-24 results in:
      dstate:   0x01600200
      node:     0
      affinity: 24-31
      effectiv: 25
      And after offlining CPU 25:
      dstate:   0x01a30000
      node:     0
      affinity: 24-31
      effectiv: 25
      which is the correct and expected result.
      Fixes: 761ea388 ("genirq: Handle managed irqs gracefully in irq_startup()")
      Reported-by: default avatarYASUAKI ISHIMATSU <yasu.isimatu@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: axboe@kernel.dk
      Cc: linux-scsi@vger.kernel.org
      Cc: Sumit Saxena <sumit.saxena@broadcom.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: mpe@ellerman.id.au
      Cc: Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com>
      Cc: Kashyap Desai <kashyap.desai@broadcom.com>
      Cc: keith.busch@intel.com
      Cc: peterz@infradead.org
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos
    • Thomas Gleixner's avatar
      genirq/cpuhotplug: Add sanity check for effective affinity mask · 60b09c51
      Thomas Gleixner authored
      The effective affinity mask handling has no safety net when the mask is not
      updated by the interrupt chip or the mask contains offline CPUs.
      If that happens the CPU unplug code fails to migrate interrupts.
      Add sanity checks and emit a warning when the mask contains only offline
      Fixes: 415fcf1a ("genirq/cpuhotplug: Use effective affinity mask")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos
    • Thomas Gleixner's avatar
      genirq: Warn when effective affinity is not updated · 19e1d4e9
      Thomas Gleixner authored
      Emit a one time warning when the effective affinity mask is enabled in
      Kconfig, but the interrupt chip does not update the mask in its
      irq_set_affinity() callback,
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos                                                                                                                                                                                                        
  16. 28 Sep, 2017 1 commit
  17. 25 Sep, 2017 2 commits
  18. 16 Sep, 2017 1 commit
    • Thomas Gleixner's avatar
      genirq: Fix cpumask check in __irq_startup_managed() · 9cb067ef
      Thomas Gleixner authored
      The result of cpumask_any_and() is invalid when result greater or equal
      nr_cpu_ids. The current check is checking for greater only. Fix it.
      Fixes: 761ea388 ("genirq: Handle managed irqs gracefully in irq_startup()")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Chen Yu <yu.c.chen@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: stable@vger.kernel.org
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/20170913213152.272283444@linutronix.de
  19. 07 Sep, 2017 1 commit
    • Thomas Gleixner's avatar
      genirq: Make sparse_irq_lock protect what it should protect · 12ac1d0f
      Thomas Gleixner authored
      for_each_active_irq() iterates the sparse irq allocation bitmap. The caller
      must hold sparse_irq_lock. Several code pathes expect that an active bit in
      the sparse bitmap also has a valid interrupt descriptor.
      Unfortunately that's not true. The (de)allocation is a two step process,
      which holds the sparse_irq_lock only across the queue/remove from the radix
      tree and the set/clear in the allocation bitmap.
      If a iteration locks sparse_irq_lock between the two steps, then it might
      see an active bit but the corresponding irq descriptor is NULL. If that is
      dereferenced unconditionally, then the kernel oopses. Of course, all
      iterator sites could be audited and fixed, but....
      There is no reason why the sparse_irq_lock needs to be dropped between the
      two steps, in fact the code becomes simpler when the mutex is held across
      both and the semantics become more straight forward, so future problems of
      missing NULL pointer checks in the iteration are avoided and all existing
      sites are fixed in one go.
      Expand the lock held sections so both operations are covered and the bitmap
      and the radixtree are in sync.
      Fixes: a05a900a ("genirq: Make sparse_lock a mutex")
      Reported-and-tested-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
  20. 06 Sep, 2017 1 commit
  21. 25 Aug, 2017 3 commits
  22. 23 Aug, 2017 1 commit
  23. 20 Aug, 2017 1 commit
  24. 18 Aug, 2017 8 commits
  25. 16 Aug, 2017 1 commit