kernel/irq/irq_test.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
irq_shutdown_and_deactivate() is normally called with the descriptor
lock held, and interrupts disabled. Nested a few levels down, it grabs
the global irq_resend_lock. Lockdep rightfully complains [1].
Grab the descriptor lock, and disable interrupts, to resolve the
complaint.
Tested with:
tools/testing/kunit/kunit.py run 'irq_test_cases*' \
--arch x86_64 --qemu_args '-smp 2' \
--kconfig_add CONFIG_DEBUG_KERNEL=y \
--kconfig_add CONFIG_PROVE_LOCKING=y \
--raw_output=all
[1]
========================================================
WARNING: possible irq lock inversion dependency detected
6.16.0-11743-g6bcdbd62bd56 #2 Tainted: G N
--------------------------------------------------------
kunit_try_catch/40 just changed the state of lock:
ffffffff898b1538 (irq_resend_lock){+...}-{2:2}, at: clear_irq_resend+0x14/0x70
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&irq_desc_lock_class){-.-.}-{2:2}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(irq_resend_lock);
local_irq_disable();
lock(&irq_desc_lock_class);
lock(irq_resend_lock);
<Interrupt>
lock(&irq_desc_lock_class);
[...]
... key at: [<ffffffff898b1538>] irq_resend_lock+0x18/0x60
... acquired at:
__lock_acquire+0x82b/0x2620
lock_acquire+0xc7/0x2c0
_raw_spin_lock+0x2b/0x40
clear_irq_resend+0x14/0x70
irq_shutdown_and_deactivate+0x29/0x80
irq_shutdown_depth_test+0x1ce/0x600
kunit_try_run_case+0x90/0x120
kunit_generic_run_threadfn_adapter+0x1c/0x40
kthread+0xf3/0x200
ret_from_fork+0x140/0x1b0
ret_from_fork_asm+0x1a/0x30
[ 5.766715] ok 2 irq_free_disabled_test
[ 5.769030]
[ 5.769106] ========================================================
[ 5.769159] WARNING: possible irq lock inversion dependency detected
[ 5.769355] 6.16.0-11743-g6bcdbd62bd56 #1 Tainted: G N
[ 5.769413] --------------------------------------------------------
[ 5.769465] kunit_try_catch/122 just changed the state of lock:
[ 5.769532] ffffffffb81ace18 (irq_resend_lock){+...}-{2:2}, at: clear_irq_resend+0x14/0x70
[ 5.769899] but this lock was taken by another, HARDIRQ-safe lock in the past:
[ 5.769967] (&irq_desc_lock_class){-.-.}-{2:2}
[ 5.769989]
[ 5.769989]
[ 5.769989] and interrupts could create inverse lock ordering between them.
...
[ 5.776956] ret_from_fork_asm+0x1a/0x30
[ 5.776983] </TASK>
[ 5.778916] # irq_shutdown_depth_test: pass:1 fail:0 skip:0 total:1
[ 5.778953] ok 3 irq_shutdown_depth_test
Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/lkml/31a761e4-8f81-40cf-aaf5-d220ba11911c@roeck-us.net/
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
On Tue, Aug 05, 2025 at 10:45:33AM -0700, Guenter Roeck wrote:
> Hi Brian,
>
> On Thu, May 22, 2025 at 02:08:01PM -0700, Brian Norris wrote:
> > * irq_shutdown_depth_test: exercises similar behavior from
> > irq_cpuhotplug_test, but directly using irq_*() APIs instead of going
> > through CPU hotplug. This still requires CONFIG_SMP, because
> > managed-affinity is stubbed out (and not all APIs are even present)
> > without it.
> >
> This test triggers warning tracebacks for me.
[...]
> Is this on purpose ?
No. I think it's an artifact of trying to imitate CPU hotplug, but doing
so insufficiently. I believe the surrounding patch fixes things.
Let me know if it helps. Thanks for the report.
kernel/irq/irq_test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irq_test.c b/kernel/irq/irq_test.c
index 5161b56a12f9..a75abebed7f2 100644
--- a/kernel/irq/irq_test.c
+++ b/kernel/irq/irq_test.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: LGPL-2.1+
+#include <linux/cleanup.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/interrupt.h>
@@ -134,7 +135,8 @@ static void irq_shutdown_depth_test(struct kunit *test)
disable_irq(virq);
KUNIT_EXPECT_EQ(test, desc->depth, 1);
- irq_shutdown_and_deactivate(desc);
+ scoped_guard(raw_spinlock_irqsave, &desc->lock)
+ irq_shutdown_and_deactivate(desc);
KUNIT_EXPECT_FALSE(test, irqd_is_activated(data));
KUNIT_EXPECT_FALSE(test, irqd_is_started(data));
--
2.50.1.565.gc32cd1483b-googOn 8/5/25 11:32, Brian Norris wrote:
> irq_shutdown_and_deactivate() is normally called with the descriptor
> lock held, and interrupts disabled. Nested a few levels down, it grabs
> the global irq_resend_lock. Lockdep rightfully complains [1].
>
> Grab the descriptor lock, and disable interrupts, to resolve the
> complaint.
>
> Tested with:
>
> tools/testing/kunit/kunit.py run 'irq_test_cases*' \
> --arch x86_64 --qemu_args '-smp 2' \
> --kconfig_add CONFIG_DEBUG_KERNEL=y \
> --kconfig_add CONFIG_PROVE_LOCKING=y \
> --raw_output=all
>
> [1]
> ========================================================
> WARNING: possible irq lock inversion dependency detected
> 6.16.0-11743-g6bcdbd62bd56 #2 Tainted: G N
> --------------------------------------------------------
> kunit_try_catch/40 just changed the state of lock:
> ffffffff898b1538 (irq_resend_lock){+...}-{2:2}, at: clear_irq_resend+0x14/0x70
> but this lock was taken by another, HARDIRQ-safe lock in the past:
> (&irq_desc_lock_class){-.-.}-{2:2}
>
> and interrupts could create inverse lock ordering between them.
>
> other info that might help us debug this:
> Possible interrupt unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(irq_resend_lock);
> local_irq_disable();
> lock(&irq_desc_lock_class);
> lock(irq_resend_lock);
> <Interrupt>
> lock(&irq_desc_lock_class);
>
> [...]
>
> ... key at: [<ffffffff898b1538>] irq_resend_lock+0x18/0x60
> ... acquired at:
> __lock_acquire+0x82b/0x2620
> lock_acquire+0xc7/0x2c0
> _raw_spin_lock+0x2b/0x40
> clear_irq_resend+0x14/0x70
> irq_shutdown_and_deactivate+0x29/0x80
> irq_shutdown_depth_test+0x1ce/0x600
> kunit_try_run_case+0x90/0x120
> kunit_generic_run_threadfn_adapter+0x1c/0x40
> kthread+0xf3/0x200
> ret_from_fork+0x140/0x1b0
> ret_from_fork_asm+0x1a/0x30
>
> [ 5.766715] ok 2 irq_free_disabled_test
> [ 5.769030]
> [ 5.769106] ========================================================
> [ 5.769159] WARNING: possible irq lock inversion dependency detected
> [ 5.769355] 6.16.0-11743-g6bcdbd62bd56 #1 Tainted: G N
> [ 5.769413] --------------------------------------------------------
> [ 5.769465] kunit_try_catch/122 just changed the state of lock:
> [ 5.769532] ffffffffb81ace18 (irq_resend_lock){+...}-{2:2}, at: clear_irq_resend+0x14/0x70
> [ 5.769899] but this lock was taken by another, HARDIRQ-safe lock in the past:
> [ 5.769967] (&irq_desc_lock_class){-.-.}-{2:2}
> [ 5.769989]
> [ 5.769989]
> [ 5.769989] and interrupts could create inverse lock ordering between them.
> ...
> [ 5.776956] ret_from_fork_asm+0x1a/0x30
> [ 5.776983] </TASK>
> [ 5.778916] # irq_shutdown_depth_test: pass:1 fail:0 skip:0 total:1
> [ 5.778953] ok 3 irq_shutdown_depth_test
>
> Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/lkml/31a761e4-8f81-40cf-aaf5-d220ba11911c@roeck-us.net/
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks for the quick turnaround!
Guenter
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 5b65258229117995eb6c4bd74995e15fb5f2cfe3
Gitweb: https://git.kernel.org/tip/5b65258229117995eb6c4bd74995e15fb5f2cfe3
Author: Brian Norris <briannorris@chromium.org>
AuthorDate: Tue, 05 Aug 2025 11:32:20 -07:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Wed, 06 Aug 2025 10:29:48 +02:00
genirq/test: Resolve irq lock inversion warnings
irq_shutdown_and_deactivate() is normally called with the descriptor lock
held, and interrupts disabled. Nested a few levels down, it grabs the
global irq_resend_lock. Lockdep rightfully complains when interrupts are
not disabled:
CPU0 CPU1
---- ----
lock(irq_resend_lock);
local_irq_disable();
lock(&irq_desc_lock_class);
lock(irq_resend_lock);
<Interrupt>
lock(&irq_desc_lock_class);
...
_raw_spin_lock+0x2b/0x40
clear_irq_resend+0x14/0x70
irq_shutdown_and_deactivate+0x29/0x80
irq_shutdown_depth_test+0x1ce/0x600
kunit_try_run_case+0x90/0x120
Grab the descriptor lock and disable interrupts, to resolve the
problem.
Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/all/aJJONEIoIiTSDMqc@google.com
Closes: https://lore.kernel.org/lkml/31a761e4-8f81-40cf-aaf5-d220ba11911c@roeck-us.net/
---
kernel/irq/irq_test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irq_test.c b/kernel/irq/irq_test.c
index 5161b56..a75abeb 100644
--- a/kernel/irq/irq_test.c
+++ b/kernel/irq/irq_test.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: LGPL-2.1+
+#include <linux/cleanup.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/interrupt.h>
@@ -134,7 +135,8 @@ static void irq_shutdown_depth_test(struct kunit *test)
disable_irq(virq);
KUNIT_EXPECT_EQ(test, desc->depth, 1);
- irq_shutdown_and_deactivate(desc);
+ scoped_guard(raw_spinlock_irqsave, &desc->lock)
+ irq_shutdown_and_deactivate(desc);
KUNIT_EXPECT_FALSE(test, irqd_is_activated(data));
KUNIT_EXPECT_FALSE(test, irqd_is_started(data));© 2016 - 2025 Red Hat, Inc.