1. 10 5月, 2019 1 次提交
  2. 06 3月, 2019 1 次提交
  3. 14 11月, 2018 1 次提交
    • L
      genirq: Fix race on spurious interrupt detection · e6d2f788
      Lukas Wunner 提交于
      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
         woken.
      
      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:
      
      time
       |  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 */
       v
      
      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
      irq_finalize_oneshot().
      
      [ tglx: Folded change log update ]
      
      Fixes: 1e77d0a1 ("genirq: Sanitize spurious interrupt detection of threaded irqs")
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NThomas 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6d2f788
  4. 03 8月, 2018 1 次提交
    • T
      genirq: Make force irq threading setup more robust · d1f0301b
      Thomas Gleixner 提交于
      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
      it.
      
      Fixes: 2a1d3ab8 ("genirq: Handle force threading of irqs with primary and thread handler")
      Reported-by: NKurt Kanzenbach <kurt.kanzenbach@linutronix.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NKurt Kanzenbach <kurt.kanzenbach@linutronix.de>
      Cc: stable@vger.kernel.org
      d1f0301b
  5. 17 7月, 2018 1 次提交
  6. 24 6月, 2018 2 次提交
    • L
      genirq: Synchronize only with single thread on free_irq() · 519cc865
      Lukas Wunner 提交于
      When pciehp is converted to threaded IRQ handling, removal of unplugged
      devices below a PCIe hotplug port happens synchronously in the IRQ thread.
      Removal of devices typically entails a call to free_irq() by their drivers.
      
      If those devices share their IRQ with the hotplug port, __free_irq()
      deadlocks because it calls synchronize_irq() to wait for all hard IRQ
      handlers as well as all threads sharing the IRQ to finish.
      
      Actually it's sufficient to wait only for the IRQ thread of the removed
      device, so call synchronize_hardirq() to wait for all hard IRQ handlers to
      finish, but no longer for any threads.  Compensate by rearranging the
      control flow in irq_wait_for_interrupt() such that the device's thread is
      allowed to run one last time after kthread_stop() has been called.
      
      kthread_stop() blocks until the IRQ thread has completed.  On completion
      the IRQ thread clears its oneshot thread_mask bit.  This is safe because
      __free_irq() holds the request_mutex, thereby preventing __setup_irq() from
      handing out the same oneshot thread_mask bit to a newly requested action.
      
      Stack trace for posterity:
          INFO: task irq/17-pciehp:94 blocked for more than 120 seconds.
          schedule+0x28/0x80
          synchronize_irq+0x6e/0xa0
          __free_irq+0x15a/0x2b0
          free_irq+0x33/0x70
          pciehp_release_ctrl+0x98/0xb0
          pcie_port_remove_service+0x2f/0x40
          device_release_driver_internal+0x157/0x220
          bus_remove_device+0xe2/0x150
          device_del+0x124/0x340
          device_unregister+0x16/0x60
          remove_iter+0x1a/0x20
          device_for_each_child+0x4b/0x90
          pcie_port_device_remove+0x1e/0x30
          pci_device_remove+0x36/0xb0
          device_release_driver_internal+0x157/0x220
          pci_stop_bus_device+0x7d/0xa0
          pci_stop_bus_device+0x3d/0xa0
          pci_stop_and_remove_bus_device+0xe/0x20
          pciehp_unconfigure_device+0xb8/0x160
          pciehp_disable_slot+0x84/0x130
          pciehp_ist+0x158/0x190
          irq_thread_fn+0x1b/0x50
          irq_thread+0x143/0x1a0
          kthread+0x111/0x130
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: linux-pci@vger.kernel.org
      Link: https://lkml.kernel.org/r/d72b41309f077c8d3bee6cc08ad3662d50b5d22a.1529828292.git.lukas@wunner.de
      519cc865
    • L
      genirq: Update code comments wrt recycled thread_mask · 836557bd
      Lukas Wunner 提交于
      Previously a race existed between __free_irq() and __setup_irq() wherein
      the thread_mask of a just removed action could be handed out to a newly
      added action and the freed irq thread would then tread on the oneshot
      mask bit of the newly added irq thread in irq_finalize_oneshot():
      
      time
       |  __free_irq()
       |    raw_spin_lock_irqsave(&desc->lock, flags);
       |    <remove action from linked list>
       |    raw_spin_unlock_irqrestore(&desc->lock, flags);
       |
       |  __setup_irq()
       |    raw_spin_lock_irqsave(&desc->lock, flags);
       |    <traverse linked list to determine oneshot mask bit>
       |    raw_spin_unlock_irqrestore(&desc->lock, flags);
       |
       |  irq_thread() of freed irq (__free_irq() waits in synchronize_irq())
       |    irq_thread_fn()
       |      irq_finalize_oneshot()
       |        raw_spin_lock_irq(&desc->lock);
       |        desc->threads_oneshot &= ~action->thread_mask;
       |        raw_spin_unlock_irq(&desc->lock);
       v
      
      The race was known at least since 2012 when it was documented in a code
      comment by commit e04268b0 ("genirq: Remove paranoid warnons and bogus
      fixups"). The race itself is harmless as nothing touches any of the
      potentially freed data after synchronize_irq().
      
      In 2017 the race was close by commit 9114014c ("genirq: Add mutex to
      irq desc to serialize request/free_irq()"), apparently inadvertantly so
      because the race is neither mentioned in the commit message nor was the
      code comment updated.  Make up for that.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: linux-pci@vger.kernel.org
      Link: https://lkml.kernel.org/r/32fc25aa35ecef4b2692f57687bb7fc2a57230e2.1529828292.git.lukas@wunner.de
      836557bd
  7. 19 6月, 2018 1 次提交
  8. 06 6月, 2018 2 次提交
  9. 20 3月, 2018 3 次提交
  10. 16 2月, 2018 1 次提交
  11. 13 11月, 2017 1 次提交
    • R
      genirq: Fix type of shifting literal 1 in __setup_irq() · ffc661c9
      Rasmus Villemoes 提交于
      If ffz() ever returns a value >= 31 then the following shift is undefined
      behaviour because the literal 1 which gets shifted is treated as signed
      integer.
      
      In practice, the bug is probably harmless, since the first undefined shift
      count is 31 which results - ignoring UB - in (int)(0x80000000). This gets
      sign extended so bit 32-63 will be set as well and all subsequent
      __setup_irq() calls would just end up hitting the -EBUSY branch.
      
      However, a sufficiently aggressive optimizer may use the UB of 1<<31
      to decide that doesn't happen, and hence elide the sign-extension
      code, so that subsequent calls can indeed get ffz > 31.
      
      In any case, the right thing to do is to make the literal 1UL.
      
      [ tglx: For this to happen a single interrupt would have to be shared by 32
        	devices. Hardware like that does not exist and would have way more
        	problems than that. ]
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20171030213548.16831-1-linux@rasmusvillemoes.dk
      ffc661c9
  12. 10 11月, 2017 1 次提交
    • M
      genirq: Track whether the trigger type has been set · 4f8413a3
      Marc Zyngier 提交于
      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")
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NPetr Cvek <petrcvekcz@gmail.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      4f8413a3
  13. 29 10月, 2017 1 次提交
    • C
      genirq: Document vcpu_info usage for percpu_devid interrupts · 250a53d6
      Christoffer Dall 提交于
      It is currently unclear how to set the VCPU affinity for a percpu_devid
      interrupt , since the Linux irq_data structure describes the state for
      multiple interrupts, one for each physical CPU on the system.  Since
      each such interrupt can be associated with different VCPUs or none at
      all, associating a single VCPU state with such an interrupt does not
      capture the necessary semantics.
      
      The implementers of irq_set_affinity are the Intel and AMD IOMMUs, and
      the ARM GIC irqchip.  The Intel and AMD callers do not appear to use
      percpu_devid interrupts, and the ARM GIC implementation only checks the
      pointer against NULL vs. non-NULL.
      
      Therefore, simply update the function documentation to explain the
      expected use in the context of percpu_devid interrupts, allowing future
      changes or additions to irqchip implementers to do the right thing.
      Signed-off-by: NChristoffer Dall <cdall@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: kvm@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Eric Auger <eric.auger@redhat.com>
      Cc: kvmarm@lists.cs.columbia.edu
      Cc: linux-arm-kernel@lists.infradead.org
      Link: https://lkml.kernel.org/r/1509093281-15225-13-git-send-email-cdall@linaro.org
      250a53d6
  14. 09 10月, 2017 2 次提交
    • T
      genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs · e43b3b58
      Thomas Gleixner 提交于
      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
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  0
      
      After offlining CPU 31 - 24
      
      dstate:   0x01a31000
                  IRQD_IRQ_DISABLED
                  IRQD_IRQ_MASKED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_AFFINITY_MANAGED
                  IRQD_MANAGED_SHUTDOWN
      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
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_SETAFFINITY_PENDING
                  IRQD_AFFINITY_MANAGED
      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
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_SETAFFINITY_PENDING
                  IRQD_AFFINITY_MANAGED
      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
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 25
      pending:  
      
      And after offlining CPU 25:
      
      dstate:   0x01a30000
                  IRQD_IRQ_DISABLED
                  IRQD_IRQ_MASKED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_MANAGED
                  IRQD_MANAGED_SHUTDOWN
      node:     0
      affinity: 24-31
      effectiv: 25
      pending:  
      
      which is the correct and expected result.
      
      Fixes: 761ea388 ("genirq: Handle managed irqs gracefully in irq_startup()")
      Reported-by: NYASUAKI ISHIMATSU <yasu.isimatu@gmail.com>
      Signed-off-by: NThomas 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
      e43b3b58
    • T
      genirq: Warn when effective affinity is not updated · 19e1d4e9
      Thomas Gleixner 提交于
      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: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos                                                                                                                                                                                                        
      19e1d4e9
  15. 26 9月, 2017 2 次提交
    • T
      genirq: Separate activation and startup · c942cee4
      Thomas Gleixner 提交于
      Activation of an interrupt and startup are currently a combo
      functionlity. That works so far, but upcoming changes require a strict
      separation because the activation can fail in future.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@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: 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: https://lkml.kernel.org/r/20170913213152.754334077@linutronix.de
      c942cee4
    • T
      genirq/debugfs: Show debug information for all irq descriptors · e0b47794
      Thomas Gleixner 提交于
      Currently the debugfs shows only information about actively used interrupts
      like /proc/irq/ does. That's fine for most cases, but not helpful when
      internals of allocated, but unused interrupt descriptors have to
      debugged. It's also useful to provide information about all descriptors so
      leaks can be debugged in a simpler way.
      
      Move the debugfs registration to the descriptor allocation code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@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: 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: https://lkml.kernel.org/r/20170913213152.355525908@linutronix.de
      e0b47794
  16. 25 9月, 2017 1 次提交
  17. 23 8月, 2017 1 次提交
  18. 12 7月, 2017 1 次提交
    • T
      genirq: Keep chip buslock across irq_request/release_resources() · 19d39a38
      Thomas Gleixner 提交于
      Moving the irq_request/release_resources() callbacks out of the spinlocked,
      irq disabled and bus locked region, unearthed an interesting abuse of the
      irq_bus_lock/irq_bus_sync_unlock() callbacks.
      
      The OMAP GPIO driver does merily power management inside of them. The
      irq_request_resources() callback of this GPIO irqchip calls a function
      which reads a GPIO register. That read aborts now because the clock of the
      GPIO block is not magically enabled via the irq_bus_lock() callback.
      
      Move the callbacks under the bus lock again to prevent this. In the
      free_irq() path this requires to drop the bus_lock before calling
      synchronize_irq() and reaquiring it before calling the
      irq_release_resources() callback.
      
      The bus lock can't be held because:
      
         1) The data which has been changed between bus_lock/un_lock is cached in
            the irq chip driver private data and needs to go out to the irq chip
            via the slow bus (usually SPI or I2C) before calling
            synchronize_irq().
      
            That's the reason why this bus_lock/unlock magic exists in the first
            place, as you cannot do SPI/I2C transactions while holding desc->lock
            with interrupts disabled.
      
         2) synchronize_irq() will actually deadlock, if there is a handler on
            flight. These chips use threaded handlers for obvious reasons, as
            they allow to do SPI/I2C communication. When the threaded handler
            returns then bus_lock needs to be taken in irq_finalize_oneshot() as
            we need to talk to the actual irq chip once more. After that the
            threaded handler is marked done, which makes synchronize_irq() return.
      
            So if we hold bus_lock accross the synchronize_irq() call, the
            handler cannot mark itself done because it blocks on the bus
            lock. That in turn makes synchronize_irq() wait forever on the
            threaded handler to complete....
      
      Add the missing unlock of desc->request_mutex in the error path of
      __free_irq() and add a bunch of comments to explain the locking and
      protection rules.
      
      Fixes: 46e48e25 ("genirq: Move irq resource handling out of spinlocked region")
      Reported-and-tested-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Reported-and-tested-by: NTony Lindgren <tony@atomide.com>
      Reported-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Not-longer-ranted-at-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      19d39a38
  19. 07 7月, 2017 1 次提交
    • D
      genirq: Allow to pass the IRQF_TIMER flag with percpu irq request · c80081b9
      Daniel Lezcano 提交于
      The irq timings infrastructure tracks when interrupts occur in order to
      statistically predict te next interrupt event.
      
      There is no point to track timer interrupts and try to predict them because
      the next expiration time is already known. This can be avoided via the
      IRQF_TIMER flag which is passed by timer drivers in request_irq(). It marks
      the interrupt as timer based which alloes to ignore these interrupts in the
      timings code.
      
      Per CPU interrupts which are requested via request_percpu_+irq() have no
      flag argument, so marking per cpu timer interrupts is not possible and they
      get tracked pointlessly.
      
      Add __request_percpu_irq() as a variant of request_percpu_irq() with a
      flags argument and make request_percpu_irq() an inline wrapper passing
      flags = 0.
      
      The flag parameter is restricted to IRQF_TIMER as all other IRQF_ flags
      make no sense for per cpu interrupts.
      
      The next step is to convert all existing users of request_percpu_irq() and
      then remove the wrapper and the underscores.
      
      [ tglx: Massaged changelog ]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Cc: nicolas.pitre@linaro.org
      Cc: vincent.guittot@linaro.org
      Cc: rafael@kernel.org
      Link: http://lkml.kernel.org/r/1499344144-3964-1-git-send-email-daniel.lezcano@linaro.org
      c80081b9
  20. 04 7月, 2017 4 次提交
  21. 24 6月, 2017 1 次提交
    • D
      genirq/timings: Add infrastructure to track the interrupt timings · b2d3d61a
      Daniel Lezcano 提交于
      The interrupt framework gives a lot of information about each interrupt. It
      does not keep track of when those interrupts occur though, which is a
      prerequisite for estimating the next interrupt arrival for power management
      purposes.
      
      Add a mechanism to record the timestamp for each interrupt occurrences in a
      per-CPU circular buffer to help with the prediction of the next occurrence
      using a statistical model.
      
      Each CPU can store up to IRQ_TIMINGS_SIZE events <irq, timestamp>, the
      current value of IRQ_TIMINGS_SIZE is 32.
      
      Each event is encoded into a single u64, where the high 48 bits are used
      for the timestamp and the low 16 bits are for the irq number.
      
      A static key is introduced so when the irq prediction is switched off at
      runtime, the overhead is near to zero.
      
      It results in most of the code in internals.h for inline reasons and a very
      few in the new file timings.c. The latter will contain more in the next patch
      which will provide the statistical model for the next event prediction.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: "Rafael J . Wysocki" <rafael@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Link: http://lkml.kernel.org/r/1498227072-5980-1-git-send-email-daniel.lezcano@linaro.org
      b2d3d61a
  22. 23 6月, 2017 6 次提交
    • T
      genirq: Add force argument to irq_startup() · 4cde9c6b
      Thomas Gleixner 提交于
      In order to handle managed interrupts gracefully on irq_startup() so they
      won't lose their assigned affinity, it's necessary to allow startups which
      keep the interrupts in managed shutdown state, if none of the assigend CPUs
      is online. This allows drivers to request interrupts w/o the CPUs being
      online, which avoid online/offline churn in drivers.
      
      Add a force argument which can override that decision and let only
      request_irq() and enable_irq() allow the managed shutdown
      handling. enable_irq() is required, because the interrupt might be
      requested with IRQF_NOAUTOEN and enable_irq() invokes irq_startup() which
      would then wreckage the assignment again. All other callers force startup
      and potentially break the assigned affinity.
      
      No functional change as this only adds the function argument.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235447.112094565@linutronix.de
      4cde9c6b
    • C
      genirq: Move pending helpers to internal.h · 137221df
      Christoph Hellwig 提交于
      So that the affinity code can reuse them.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20170619235445.109426284@linutronix.de
      137221df
    • T
      genirq: Move initial affinity setup to irq_startup() · 2e051552
      Thomas Gleixner 提交于
      The startup vs. setaffinity ordering of interrupts depends on the
      IRQF_NOAUTOEN flag. Chained interrupts are not getting any affinity
      assignment at all.
      
      A regular interrupt is started up and then the affinity is set. A
      IRQF_NOAUTOEN marked interrupt is not started up, but the affinity is set
      nevertheless.
      
      Move the affinity setup to startup_irq() so the ordering is always the same
      and chained interrupts get the proper default affinity assigned as well.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235445.020534783@linutronix.de
      2e051552
    • T
      genirq: Rename setup_affinity() to irq_setup_affinity() · 43564bd9
      Thomas Gleixner 提交于
      Rename it with a proper irq_ prefix and make it available for other files
      in the core code. Preparatory patch for moving the irq affinity setup
      around.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235444.928501004@linutronix.de
      43564bd9
    • T
      genirq: Remove mask argument from setup_affinity() · cba4235e
      Thomas Gleixner 提交于
      No point to have this alloc/free dance of cpumasks. Provide a static mask
      for setup_affinity() and protect it proper.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235444.851571573@linutronix.de
      cba4235e
    • T
      genirq/debugfs: Add proper debugfs interface · 087cdfb6
      Thomas Gleixner 提交于
      Debugging (hierarchical) interupt domains is tedious as there is no
      information about the hierarchy and no information about states of
      interrupts in the various domain levels.
      
      Add a debugfs directory 'irq' and subdirectories 'domains' and 'irqs'.
      
      The domains directory contains the domain files. The content is information
      about the domain. If the domain is part of a hierarchy then the parent
      domains are printed as well.
      
      # ls /sys/kernel/debug/irq/domains/
      default     INTEL-IR-2	    INTEL-IR-MSI-2  IO-APIC-IR-2  PCI-MSI
      DMAR-MSI    INTEL-IR-3	    INTEL-IR-MSI-3  IO-APIC-IR-3  unknown-1
      INTEL-IR-0  INTEL-IR-MSI-0  IO-APIC-IR-0    IO-APIC-IR-4  VECTOR
      INTEL-IR-1  INTEL-IR-MSI-1  IO-APIC-IR-1    PCI-HT
      
      # cat /sys/kernel/debug/irq/domains/VECTOR 
      name:   VECTOR
       size:   0
       mapped: 216
       flags:  0x00000041
      
      # cat /sys/kernel/debug/irq/domains/IO-APIC-IR-0 
      name:   IO-APIC-IR-0
       size:   24
       mapped: 19
       flags:  0x00000041
       parent: INTEL-IR-3
          name:   INTEL-IR-3
           size:   65536
           mapped: 167
           flags:  0x00000041
           parent: VECTOR
              name:   VECTOR
               size:   0
               mapped: 216
               flags:  0x00000041
      
      Unfortunately there is no per cpu information about the VECTOR domain (yet).
      
      The irqs directory contains detailed information about mapped interrupts.
      
      # cat /sys/kernel/debug/irq/irqs/3
      handler:  handle_edge_irq
      status:   0x00004000
      istate:   0x00000000
      ddepth:   1
      wdepth:   0
      dstate:   0x01018000
                  IRQD_IRQ_DISABLED
                  IRQD_SINGLE_TARGET
                  IRQD_MOVE_PCNTXT
      node:     0
      affinity: 0-143
      effectiv: 0
      pending:  
      domain:  IO-APIC-IR-0
       hwirq:   0x3
       chip:    IR-IO-APIC
        flags:   0x10
                   IRQCHIP_SKIP_SET_WAKE
       parent:
          domain:  INTEL-IR-3
           hwirq:   0x20000
           chip:    INTEL-IR
            flags:   0x0
           parent:
              domain:  VECTOR
               hwirq:   0x3
               chip:    APIC
                flags:   0x0
      
      This was developed to simplify the debugging of the managed affinity
      changes.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235444.537566163@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      087cdfb6
  23. 13 6月, 2017 1 次提交
  24. 04 6月, 2017 2 次提交
  25. 19 4月, 2017 1 次提交