linux-stable.git/kernel/irq, branch v6.5.2

genirq: Fix software resend lockup and nested resend

2023-08-26T17:14:31+00:00

The switch to using hlist for managing software resend of interrupts
broke resend in at least two ways:

First, unconditionally adding interrupt descriptors to the resend list can
corrupt the list when the descriptor in question has already been
added. This causes the resend tasklet to loop indefinitely with interrupts
disabled as was recently reported with the Lenovo ThinkPad X13s after
threaded NAPI was disabled in the ath11k WiFi driver.

This bug is easily fixed by restoring the old semantics of irq_sw_resend()
so that it can be called also for descriptors that have already been marked
for resend.

Second, the offending commit also broke software resend of nested
interrupts by simply discarding the code that made sure that such
interrupts are retriggered using the parent interrupt.

Add back the corresponding code that adds the parent descriptor to the
resend list.

Fixes: bc06a9e08742 ("genirq: Use hlist for managing resend handlers")
Signed-off-by: Johan Hovold 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Marc Zyngier 
Link: https://lore.kernel.org/lkml/20230809073432.4193-1-johan+linaro@kernel.org/
Link: https://lore.kernel.org/r/20230826154004.1417-1-johan+linaro@kernel.org

irqdomain: Use return value of strreplace()

2023-06-30T09:13:44+00:00

Since strreplace() returns the pointer to the string itself, use it
directly.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20230628150251.17832-1-andriy.shevchenko@linux.intel.com

Merge tag 'irqchip-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

2023-06-26T09:05:49+00:00

Pull irqchip updates from Marc Zyngier:

  - A number of Loogson/Loogarch fixes

  - Allow the core code to retrigger an interrupt that has
    fired while the same interrupt is being handled on another
    CPU, papering over a GICv3 architecture issue

  - Work around an integration problem on ASR8601, where the CPU
    numbering isn't representable in the GIC implementation...

  - Add some missing interrupt to the STM32 irqchip

  - A bunch of warning squashing triggered by W=1 builds

Link: https://lore.kernel.org/r/20230623224345.3577134-1-maz@kernel.org

Merge branch irq/misc-6.5 into irq/irqchip-next

2023-06-21T12:53:41+00:00

* irq/misc-6.5:
  : .
  : Misc cleanups:
  :
  : - Add a number of missing prototypes
  : - Mark global symbol as static where needed
  : - Drop some now useless non-DT code paths
  : - Add a missing interrupt mapping to the STM32 irqchip
  : - Silence another STM32 warning when building with W=1
  : - Fix the jcore-aic driver that actually never worked...
  : .
  Revert "irqchip/mxs: Include linux/irqchip/mxs.h"
  irqchip/jcore-aic: Fix missing allocation of IRQ descriptors
  irqchip/stm32-exti: Fix warning on initialized field overwritten
  irqchip/stm32-exti: Add STM32MP15xx IWDG2 EXTI to GIC map
  irqchip/gicv3: Add a iort_pmsi_get_dev_id() prototype
  irqchip/mxs: Include linux/irqchip/mxs.h
  irqchip/clps711x: Remove unused clps711x_intc_init() function
  irqchip/mmp: Remove non-DT codepath
  irqchip/ftintc010: Mark all function static
  irqdomain: Include internals.h for function prototypes

Signed-off-by: Marc Zyngier

irqdomain: Include internals.h for function prototypes

2023-06-17T06:20:45+00:00

irq_domain_debugfs_init() is defined in irqdomain.c, but the
declaration is in a header that is not included here:

kernel/irq/irqdomain.c:1965:13: error: no previous prototype for 'irq_domain_debugfs_init' [-Werror=missing-prototypes]

Signed-off-by: Arnd Bergmann 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20230516200432.554240-1-arnd@kernel.org

genirq: Allow fasteoi handler to resend interrupts on concurrent handling

2023-06-16T11:22:35+00:00

There is a class of interrupt controllers out there that, once they
have signalled a given interrupt number, will still signal incoming
instances of the *same* interrupt despite the original interrupt
not having been EOIed yet.

As long as the new interrupt reaches the *same* CPU, nothing bad
happens, as that CPU still has its interrupts globally disabled,
and we will only take the new interrupt once the interrupt has
been EOIed.

However, things become more "interesting" if an affinity change comes
in while the interrupt is being handled. More specifically, while
the per-irq lock is being dropped. This results in the affinity change
taking place immediately. At this point, there is nothing that prevents
the interrupt from firing on the new target CPU. We end-up with the
interrupt running concurrently on two CPUs, which isn't a good thing.

And that's where things become worse: the new CPU notices that the
interrupt handling is in progress (irq_may_run() return false), and
*drops the interrupt on the floor*.

The whole race looks like this:

           CPU 0             |          CPU 1
-----------------------------|-----------------------------
interrupt start              |
  handle_fasteoi_irq         | set_affinity(CPU 1)
    handler                  |
    ...                      | interrupt start
    ...                      |   handle_fasteoi_irq -> early out
  handle_fasteoi_irq return  | interrupt end
interrupt end                |

If the interrupt was an edge, too bad. The interrupt is lost, and
the system will eventually die one way or another. Not great.

A way to avoid this situation is to detect this problem at the point
we handle the interrupt on the new target. Instead of dropping the
interrupt, use the resend mechanism to force it to be replayed.

Also, in order to limit the impact of this workaround to the pathetic
architectures that require it, gate it behind a new irq flag aptly
named IRQD_RESEND_WHEN_IN_PROGRESS.

Suggested-by: Marc Zyngier 
Signed-off-by: James Gowans 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: KarimAllah Raslan 
Cc: Yipeng Zou 
Cc: Zhang Jianhua 
[maz: reworded commit mesage]
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20230608120021.3273400-3-jgowans@amazon.com

genirq: Expand doc for PENDING and REPLAY flags

2023-06-16T11:22:05+00:00

Adding a bit more info about what the flags are used for may help future
code readers.

Signed-off-by: James Gowans 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Liao Chang 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20230608120021.3273400-2-jgowans@amazon.com

Merge tag 'for-linus-6.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2023-05-27T16:42:56+00:00

Pull xen fixes from Juergen Gross:

 - a double free fix in the Xen pvcalls backend driver

 - a fix for a regression causing the MSI related sysfs entries to not
   being created in Xen PV guests

 - a fix in the Xen blkfront driver for handling insane input data
   better

* tag 'for-linus-6.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  x86/pci/xen: populate MSI sysfs entries
  xen/pvcalls-back: fix double frees with pvcalls_new_active_socket()
  xen/blkfront: Only check REQ_FUA for writes

x86/pci/xen: populate MSI sysfs entries

2023-05-24T16:08:49+00:00

Commit bf5e758f02fc ("genirq/msi: Simplify sysfs handling") reworked the
creation of sysfs entries for MSI IRQs. The creation used to be in
msi_domain_alloc_irqs_descs_locked after calling ops->domain_alloc_irqs.
Then it moved into __msi_domain_alloc_irqs which is an implementation of
domain_alloc_irqs. However, Xen comes with the only other implementation
of domain_alloc_irqs and hence doesn't run the sysfs population code
anymore.

Commit 6c796996ee70 ("x86/pci/xen: Fixup fallout from the PCI/MSI
overhaul") set the flag MSI_FLAG_DEV_SYSFS for the xen msi_domain_info
but that doesn't actually have an effect because Xen uses it's own
domain_alloc_irqs implementation.

Fix this by making use of the fallback functions for sysfs population.

Fixes: bf5e758f02fc ("genirq/msi: Simplify sysfs handling")
Signed-off-by: Maximilian Heyne 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/20230503131656.15928-1-mheyne@amazon.de
Signed-off-by: Juergen Gross

genirq: Use a maple tree for interrupt descriptor management

2023-05-24T09:39:44+00:00

The current implementation uses a static bitmap for interrupt descriptor
allocation and a radix tree to pointer store the pointer for lookup.

However, the size of the bitmap is constrained by the build time macro
MAX_SPARSE_IRQS, which may not be sufficient to support high-end servers,
particularly those with GICv4.1 hardware, which require a large interrupt
space to cover LPIs and vSGIs.

Replace the bitmap and the radix tree with a maple tree, which not only
stores pointers for lookup, but also provides a mechanism to find free
ranges. That removes the build time hardcoded upper limit.

Signed-off-by: Shanker Donthineni 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20230519134902.1495562-4-sdonthineni@nvidia.com