linux.git/kernel/irq/debugfs.c, branch v6.18.21

genirq: Bump the size of the local variable for sprintf()

2025-05-15T14:28:09+00:00

GCC is not happy about a sprintf() call on a buffer that might be too small
for the given formatting string.

kernel/irq/debugfs.c:233:26: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]

Fix this by bumping the size of the local variable for sprintf().

Reported-by: kernel test robot 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20250515085516.2913290-1-andriy.shevchenko@linux.intel.com
Closes: https://lore.kernel.org/oe-kbuild-all/202505151057.xbyXAbEn-lkp@intel.com/

genirq: Consistently use '%u' format specifier for unsigned int variables

2025-05-13T07:43:32+00:00

There are three cases in the genirq code when the irq, as an unsigned
integer variable, is converted to text representation by sprintf().
In two cases it uses '%d' specifier which is for signed values. While
it's not a problem right now, potentially it might be in the future
in case too big (> INT_MAX) number will appear there.

Consistently use '%u' format specifier for @irq which is declared as
unsigned int in all these cases.

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

genirq/debugfs: Convert to lock guards

2025-05-07T07:08:12+00:00

Convert all lock/unlock pairs to guards and tidy up the code.

No functional change.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/all/20250429065420.620200108@linutronix.de

genirq: Remove IRQ_MOVE_PCNTXT and related code

2025-01-15T20:38:53+00:00

Now that x86 is converted over to use the IRQCHIP_MOVE_DEFERRED flags,
remove IRQ*_MOVE_PCNTXT and related code.

Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20241210103335.626707225@linutronix.de

genirq: Provide IRQCHIP_MOVE_DEFERRED

2025-01-15T09:56:22+00:00

The logic of GENERIC_PENDING_IRQ is backwards for historical reasons. Most
interrupt controllers allow to move the interrupt from arbitrary
contexts. If GENERIC_PENDING_IRQ is enabled by an architecture to support a
chip, which requires the affinity change to happen in interrupt context,
all other chips have to be marked with IRQF_MOVE_PCNTXT.

That's tedious and there is no real good reason for the extra flags in the
irq descriptor and the irq data status fields. In fact the decision whether
interrupts can be moved in arbitrary context or not is a property of the
interrupt chip.

To simplify adoption for RISC-V provide a new mechanism which is enabled
via a config switch and allows to add a flag to irq_chip::flags to request
that interrupt affinity changes are deferred. Setting the top level chip of
an interrupt evaluates the flag and maps it into the existing logic.

The config switch and the various PCNTXT flags are temporary until x86 is
converted over to this scheme. This intermediate step also allows trivial
backporting of the mechanism to plug the affinity change race of various
RISC-V interrupt controllers.

Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20241210103335.500314436@linutronix.de

genirq/debugfs: Print irqdomain flags as human-readable strings

2024-06-03T10:24:51+00:00

Improve the readability of irqdomain debugging information in debugfs by
printing the flags field of domain files as human-readable strings instead
of a raw bitmask, which aligned with the existing style used for irqchip
flags in the irq debug files.

Before:
	#cat :cpus:cpu@0:interrupt-controller
	name:   :cpus:cpu@0:interrupt-controller
	 size:   0
	 mapped: 2
	 flags:  0x00000003

After:
	#cat :cpus:cpu@0:interrupt-controller
	name:   :cpus:cpu@0:interrupt-controller
	 size:   0
	 mapped: 3
	 flags:  0x00000003
	            IRQ_DOMAIN_FLAG_HIERARCHY
	            IRQ_DOMAIN_NAME_ALLOCATED

Signed-off-by: Jinjie Ruan 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20240529091628.3666379-1-ruanjinjie@huawei.com

x86/apic/msi: Fix misconfigured non-maskable MSI quirk

2023-10-26T11:53:06+00:00

commit ef8dd01538ea ("genirq/msi: Make interrupt allocation less
convoluted"), reworked the code so that the x86 specific quirk for affinity
setting of non-maskable PCI/MSI interrupts is not longer activated if
necessary.

This could be solved by restoring the original logic in the core MSI code,
but after a deeper analysis it turned out that the quirk flag is not
required at all.

The quirk is only required when the PCI/MSI device cannot mask the MSI
interrupts, which in turn also prevents reservation mode from being enabled
for the affected interrupt.

This allows ot remove the NOMASK quirk bit completely as msi_set_affinity()
can instead check whether reservation mode is enabled for the interrupt,
which gives exactly the same answer.

Even in the momentary non-existing case that the reservation mode would be
not set for a maskable MSI interrupt this would not cause any harm as it
just would cause msi_set_affinity() to go needlessly through the
functionaly equivalent slow path, which works perfectly fine with maskable
interrupts as well.

Rework msi_set_affinity() to query the reservation mode and remove all
NOMASK quirk logic from the core code.

[ tglx: Massaged changelog ]

Fixes: ef8dd01538ea ("genirq/msi: Make interrupt allocation less convoluted")
Suggested-by: Thomas Gleixner 
Signed-off-by: Koichiro Den 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231026032036.2462428-1-den@valinux.co.jp

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: Return a const cpumask from irq_data_get_affinity_mask

2022-07-07T08:38:04+00:00

Now that the irq_data_update_affinity helper exists, enforce its use
by returning a a const cpumask from irq_data_get_affinity_mask.

Since the previous commit already updated places that needed to call
irq_data_update_affinity, this commit updates the remaining code that
either did not modify the cpumask or immediately passed the modified
mask to irq_set_affinity.

Signed-off-by: Samuel Holland 
Reviewed-by: Michael Kelley 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20220701200056.46555-8-samuel@sholland.org

gpio: Don't fiddle with irqchips marked as immutable

2022-04-19T14:22:25+00:00

In order to move away from gpiolib messing with the internals of
unsuspecting irqchips, add a flag by which irqchips advertise
that they are not to be messed with, and do solemnly swear that
they correctly call into the gpiolib helpers when required.

Also nudge the users into converting their drivers to the
new model.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Bartosz Golaszewski 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20220419141846.598305-2-maz@kernel.org