linux-kernel - [PATCH v2 0/2] genirq: Retain depth for managed IRQs across CPU hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250514201353.3481400-1-briannorris@chromium.org>
Date: Wed, 14 May 2025 13:13:15 -0700
From: Brian Norris <briannorris@...omium.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Tsai Sung-Fu <danielsftsai@...gle.com>,
	Douglas Anderson <dianders@...omium.org>,
	linux-kernel@...r.kernel.org,
	Brian Norris <briannorris@...omium.org>
Subject: [PATCH v2 0/2] genirq: Retain depth for managed IRQs across CPU hotplug

v1:
 https://lore.kernel.org/lkml/20250513224402.864767-1-briannorris@chromium.org/
 [PATCH 0/2] genirq: Retain disable-depth across irq_{shutdown,startup}()

I'm seeing problems in a driver that:
(a) requests an affinity-managed IRQ (struct
    irq_affinity_desc::is_managed == 1);
(b) disables that IRQ (disable_irq()); and
(c) undergoes CPU hotplug for the affined CPU.

When we do the above, the genirq core leaves the IRQ in a different
state than it started -- the kernel IRQ is re-enabled after CPU hot
unplug/plug.

This problem seems to stem from the behavior of irq_shutdown() and
irq_shutdown(): that they assume they always run with an enabled IRQ,
and can simply set depth to 1 and 0 respectively.

I incorporate a fix suggested by Thomas Gleixner in patch 1, and provide
some new kunit test cases for this area in patch 2.

Side note: I understand my colleague has reported other issues related
to the same code:

  Subject: [PATCH] genirq/PM: Fix IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND if depth > 1
  https://lore.kernel.org/lkml/20250512173250.1.If5c00cf9f08732f4af5f104ae59b8785c7f69536@changeid/

We're addressing different problems, but they do happen to hit on some
of the same awkwardness in irq_startup(). These two patches would
probably need to be reconciled in some way.

Changes in v2:
 * Adapt Thomas Gleixner's alternative solution, to focus only on CPU
   hotplug cases
 * add request_irq()/disable_irq()/free_irq()/request_irq() test
   sequence
 * clean up more resources in tests
 * move tests to patch 2 (i.e., after bugs are fixed and tests pass)
 * adapt to irq_startup_managed() (new API)

Brian Norris (2):
  genirq: Retain depth for managed IRQs across CPU hotplug
  genirq: Add kunit tests for depth counts

 kernel/irq/Kconfig      |  11 ++
 kernel/irq/Makefile     |   1 +
 kernel/irq/chip.c       |  22 +++-
 kernel/irq/cpuhotplug.c |   2 +-
 kernel/irq/internals.h  |   1 +
 kernel/irq/irq_test.c   | 229 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 264 insertions(+), 2 deletions(-)
 create mode 100644 kernel/irq/irq_test.c

-- 
2.49.0.1045.g170613ef41-goog