[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31a761e4-8f81-40cf-aaf5-d220ba11911c@roeck-us.net>
Date: Tue, 5 Aug 2025 10:45:33 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Brian Norris <briannorris@...omium.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Tsai Sung-Fu <danielsftsai@...gle.com>,
Douglas Anderson <dianders@...omium.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] genirq: Add kunit tests for depth counts
Hi Brian,
On Thu, May 22, 2025 at 02:08:01PM -0700, Brian Norris wrote:
> There have been a few bugs and/or misunderstandings about the reference
> counting, and startup/shutdown behaviors in the IRQ core and related CPU
> hotplug code. These 4 test cases try to capture a few interesting cases.
>
> * irq_disable_depth_test: basic request/disable/enable sequence
>
> * irq_free_disabled_test: request/disable/free/re-request sequence -
> this catches errors on previous revisions of my work
>
> * irq_cpuhotplug_test: exercises managed-affinity IRQ + CPU hotplug.
> This captures a problematic test case that I've fixed.
> This test requires CONFIG_SMP and a hotpluggable CPU#1.
>
> * 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.
[ 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
Is this on purpose ?
Thanks,
Guenter
Powered by blists - more mailing lists