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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ