[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220216090845.1278114-1-maz@kernel.org>
Date: Wed, 16 Feb 2022 09:08:43 +0000
From: Marc Zyngier <maz@...nel.org>
To: linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Marcin Wojtas <mw@...ihalf.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
John Garry <john.garry@...wei.com>, kernel-team@...roid.com
Subject: [PATCH 0/2] net: mvpp2: Survive CPU hotplug events
I recently realised that playing with CPU hotplug on a system equiped
with a set of MVPP2 devices (Marvell 8040) was fraught with danger and
would result in a rapid lockup or panic.
As it turns out, the per-CPU nature of the MVPP2 interrupts are
getting in the way. A good solution for this seems to rely on the
kernel's managed interrupt approach, where the core kernel will not
move interrupts around as the CPUs for down, but will simply disable
the corresponding interrupt.
Converting the driver to this requires a bit of refactoring in the IRQ
subsystem to expose the required primitive, as well as a bit of
surgery in the driver itself.
Note that although the system now survives such event, the driver
seems to assume that all queues are always active and doesn't inform
the device that a CPU has gone away. Someout who actually understand
this driver should have a look at it.
Patches on top of 5.17-rc3, lightly tested on a McBin.
Marc Zyngier (2):
genirq: Extract irq_set_affinity_masks() from
devm_platform_get_irqs_affinity()
net: mvpp2: Convert to managed interrupts to fix CPU HP issues
drivers/base/platform.c | 20 +-----
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 -
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 67 ++++++++++---------
include/linux/interrupt.h | 8 +++
kernel/irq/affinity.c | 27 ++++++++
5 files changed, 72 insertions(+), 51 deletions(-)
--
2.30.2
Powered by blists - more mailing lists