linux.git/arch/x86/kernel/apic/vector.c, branch v4.16

x86/apic/vector: Handle vector release on CPU unplug correctly

2018-02-23T07:02:00+00:00

When a irq vector is replaced, then the previous vector is normally
released when the first interrupt happens on the new vector. If the target
CPU of the previous vector is already offline when the new vector is
installed, then the previous vector is silently discarded, which leads to
accounting issues causing suspend failures and other problems.

Adjust the logic so that the previous vector is freed in the underlying
matrix allocator to ensure that the accounting stays correct.

Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
Reported-by: Yuriy Vostrikov 
Signed-off-by: Thomas Gleixner 
Tested-by: Yuriy Vostrikov 
Cc: Peter Zijlstra 
Cc: Randy Dunlap 
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180222112316.930791749@linutronix.de
Signed-off-by: Ingo Molnar

x86/apic/vector: Fix off by one in error path

2018-01-17T11:11:36+00:00

Keith reported the following warning:

WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120
  x86_vector_free_irqs+0xa1/0x180
  x86_vector_alloc_irqs+0x1e4/0x3a0
  msi_domain_alloc+0x62/0x130

The reason for this is that if the vector allocation fails the error
handling code tries to free the failed vector as well, which causes the
above imbalance warning to trigger.

Adjust the error path to handle this correctly.

Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors")
Reported-by: Keith Busch 
Signed-off-by: Thomas Gleixner 
Tested-by: Keith Busch 
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos

genirq/msi, x86/vector: Prevent reservation mode for non maskable MSI

2017-12-29T20:13:05+00:00

The new reservation mode for interrupts assigns a dummy vector when the
interrupt is allocated and assigns a real vector when the interrupt is
requested. The reservation mode prevents vector pressure when devices with
a large amount of queues/interrupts are initialized, but only a minimal
subset of those queues/interrupts is actually used.

This mode has an issue with MSI interrupts which cannot be masked. If the
driver is not careful or the hardware emits an interrupt before the device
irq is requestd by the driver then the interrupt ends up on the dummy
vector as a spurious interrupt which can cause malfunction of the device or
in the worst case a lockup of the machine.

Change the logic for the reservation mode so that the early activation of
MSI interrupts checks whether:

 - the device is a PCI/MSI device
 - the reservation mode of the underlying irqdomain is activated
 - PCI/MSI masking is globally enabled
 - the PCI/MSI device uses either MSI-X, which supports masking, or
   MSI with the maskbit supported.

If one of those conditions is false, then clear the reservation mode flag
in the irq data of the interrupt and invoke irq_domain_activate_irq() with
the reserve argument cleared. In the x86 vector code, clear the can_reserve
flag in the vector allocation data so a subsequent free_irq() won't create
the same situation again. The interrupt stays assigned to a real vector
until pci_disable_msi() is invoked and all allocations are undone.

Fixes: 4900be83602b ("x86/vector/msi: Switch to global reservation mode")
Reported-by: Alexandru Chirvasitu 
Reported-by: Andy Shevchenko 
Signed-off-by: Thomas Gleixner 
Tested-by: Alexandru Chirvasitu 
Tested-by: Andy Shevchenko 
Cc: Dou Liyang 
Cc: Pavel Machek 
Cc: Maciej W. Rozycki 
Cc: Mikael Pettersson 
Cc: Josh Poulson 
Cc: Mihai Costache 
Cc: Stephen Hemminger 
Cc: Marc Zyngier 
Cc: linux-pci@vger.kernel.org
Cc: Haiyang Zhang 
Cc: Dexuan Cui 
Cc: Simon Xiao 
Cc: Saeed Mahameed 
Cc: Jork Loeser 
Cc: Bjorn Helgaas 
Cc: devel@linuxdriverproject.org
Cc: KY Srinivasan 
Cc: Alan Cox 
Cc: Sakari Ailus ,
Cc: linux-media@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1712291406420.1899@nanos
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1712291409460.1899@nanos

genirq/irqdomain: Rename early argument of irq_domain_activate_irq()

2017-12-29T20:13:04+00:00

The 'early' argument of irq_domain_activate_irq() is actually used to
denote reservation mode. To avoid confusion, rename it before abuse
happens.

No functional change.

Fixes: 72491643469a ("genirq/irqdomain: Update irq_domain_ops.activate() signature")
Signed-off-by: Thomas Gleixner 
Cc: Alexandru Chirvasitu 
Cc: Andy Shevchenko 
Cc: Dou Liyang 
Cc: Pavel Machek 
Cc: Maciej W. Rozycki 
Cc: Mikael Pettersson 
Cc: Josh Poulson 
Cc: Mihai Costache 
Cc: Stephen Hemminger 
Cc: Marc Zyngier 
Cc: linux-pci@vger.kernel.org
Cc: Haiyang Zhang 
Cc: Dexuan Cui 
Cc: Simon Xiao 
Cc: Saeed Mahameed 
Cc: Jork Loeser 
Cc: Bjorn Helgaas 
Cc: devel@linuxdriverproject.org
Cc: KY Srinivasan 
Cc: Alan Cox 
Cc: Sakari Ailus ,
Cc: linux-media@vger.kernel.org

x86/vector: Use IRQD_CAN_RESERVE flag

2017-12-29T20:13:04+00:00

Set the new CAN_RESERVE flag when the initial reservation for an interrupt
happens. The flag is used in a subsequent patch to disable reservation mode
for a certain class of MSI devices.

Signed-off-by: Thomas Gleixner 
Tested-by: Alexandru Chirvasitu 
Tested-by: Andy Shevchenko 
Cc: Dou Liyang 
Cc: Pavel Machek 
Cc: Maciej W. Rozycki 
Cc: Mikael Pettersson 
Cc: Josh Poulson 
Cc: Mihai Costache 
Cc: Stephen Hemminger 
Cc: Marc Zyngier 
Cc: linux-pci@vger.kernel.org
Cc: Haiyang Zhang 
Cc: Dexuan Cui 
Cc: Simon Xiao 
Cc: Saeed Mahameed 
Cc: Jork Loeser 
Cc: Bjorn Helgaas 
Cc: devel@linuxdriverproject.org
Cc: KY Srinivasan 
Cc: Alan Cox 
Cc: Sakari Ailus ,
Cc: linux-media@vger.kernel.org

x86: Fix Sparse warnings about non-static functions

2017-12-06T18:32:58+00:00

Functions x86_vector_debug_show(), uv_handle_nmi() and uv_nmi_setup_common()
are local to the source and do not need to be in global scope, so make them
static.

Fixes up various sparse warnings.

Signed-off-by: Colin Ian King 
Acked-by: Mike Travis 
Cc: H. Peter Anvin 
Cc: Jiri Kosina 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Cc: kernel-janitors@vger.kernel.org
Cc: travis@sgi.com
Link: http://lkml.kernel.org/r/20171206173358.24388-1-colin.king@canonical.com
Signed-off-by: Ingo Molnar

x86/PCI: Remove unused HyperTransport interrupt support

2017-11-23T19:18:18+00:00

There are no in-tree callers of ht_create_irq(), the driver interface for
HyperTransport interrupts, left.  Remove the unused entry point and all the
supporting code.

See 8b955b0dddb3 ("[PATCH] Initial generic hypertransport interrupt
support").

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Thomas Gleixner 
Acked-by: "Eric W. Biederman" 
Cc: Andi Kleen 
Cc: Greg Kroah-Hartman 
Cc: linux-pci@vger.kernel.org
Cc: Benjamin Herrenschmidt 
Link: https://lkml.kernel.org/r/20171122221337.3877.23362.stgit@bhelgaas-glaptop.roam.corp.google.com

x86/vector: Use correct per cpu variable in free_moved_vector()

2017-10-17T14:45:09+00:00

free_moved_vector() accesses the per cpu vector array with this_cpu_write()
to clear the vector. The function has two call sites:

 1) The vector cleanup IPI
 2) The force_complete_move() code path

For #1 this_cpu_write() is correct as it runs on the CPU on which the
vector needs to be freed.

For #2 this_cpu_write() is wrong because the function is called from an
outgoing CPU which is not necessarily the CPU on which the previous vector
needs to be freed. As a result it sets the vector on the outgoing CPU to
NULL, which is pointless as that CPU does not handle interrupts
anymore. What's worse is that it leaves the vector on the previous target
CPU in place which later on triggers the BUG_ON(vector) in the vector
allocation code when the vector gets reused. That's possible because the
bitmap allocator entry of that CPU is freed correctly.

Always use the CPU to which the vector was associated and clear the vector
entry on that CPU. Fixup the tracepoint as well so it tracks on which CPU
the vector gets removed.

Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
Reported-by: Petri Latvala 
Signed-off-by: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Tony Luck 
Cc: Len Brown 
Cc: Marc Zyngier 
Cc: Joerg Roedel 
Cc: "Rafael J. Wysocki" 
Cc: Steven Rostedt 
Cc: Christoph Hellwig 
Cc: Peter Zijlstra 
Cc: Rui Zhang 
Cc: Borislav Petkov 
Cc: Paolo Bonzini 
Cc: Boris Ostrovsky 
Cc: "K. Y. Srinivasan" 
Cc: Arjan van de Ven 
Cc: Alok Kataria 
Cc: Dan Williams 
Cc: Yu Chen 
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710161614430.1973@nanos

x86/apic/vector: Ignore set_affinity call for inactive interrupts

2017-10-12T10:58:15+00:00

The core interrupt code can call the affinity setter for inactive
interrupts under certain circumstances.

For inactive intererupts which use managed or reservation mode this is a
pointless exercise as the activation will assign a vector which fits the
destination mask.

Check for this and return w/o going through the vector assignment.

Signed-off-by: Thomas Gleixner

x86/vector: Respect affinity mask in irq descriptor

2017-09-25T18:52:03+00:00

The interrupt descriptor has a preset affinity mask at allocation
time, which is usually the default affinity mask.

The current code does not respect that mask and places the vector at some
random CPU, which gets corrected later by a set_affinity() call. That's
silly because the vector allocation can respect the mask upfront and place
the interrupt on a CPU which is in the mask. If that fails, then the
affinity is broken and a interrupt assigned on any online CPU.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Yu Chen 
Acked-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Tony Luck 
Cc: Marc Zyngier 
Cc: Alok Kataria 
Cc: Joerg Roedel 
Cc: "Rafael J. Wysocki" 
Cc: Steven Rostedt 
Cc: Christoph Hellwig 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Paolo Bonzini 
Cc: Rui Zhang 
Cc: "K. Y. Srinivasan" 
Cc: Arjan van de Ven 
Cc: Dan Williams 
Cc: Len Brown 
Link: https://lkml.kernel.org/r/20170913213156.431670325@linutronix.de