linux-kernel - Re: [Question] Detecting Sleep-in-Atomic Context in PREEMPT_RT via RV (Runtime Verification) monitor rtapp:sleep

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] [day] [month] [year] [list]

Message-ID: <ee8474631ce309539918e17b60e4ca150327115d.camel@redhat.com>
Date: Mon, 22 Dec 2025 08:40:30 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Yunseong Kim <ysk@...lloc.com>, Nam Cao <namcao@...utronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, rostedt@...dmis.org, 
 Tomas Glozar <tglozar@...hat.com>, Shung-Hsi Yu <shung-hsi.yu@...e.com>,
 Byungchul Park <byungchul@...com>, 	syzkaller@...glegroups.com,
 linux-rt-devel@...ts.linux.dev, LKML	 <linux-kernel@...r.kernel.org>, Dan
 Carpenter <dan.carpenter@...aro.org>
Subject: Re: [Question] Detecting Sleep-in-Atomic Context in PREEMPT_RT via
 RV (Runtime Verification) monitor rtapp:sleep

On Thu, 2025-12-11 at 16:58 +0900, Yunseong Kim wrote:
> I am currently considering how to model this to cover cases that go 
> beyond what CONFIG_DEBUG_ATOMIC_SLEEP covers.
> 
> My specific concern is about custom functions where might_sleep() might 
> be missing. In such cases, if the code hits a fast path (no scheduling),
> CONFIG_DEBUG_ATOMIC_SLEEP won't trigger. I'm wondering if RV can detect
> these potential bugs.

Hi Yunseong,

I finally got to reflect a bit more on this.
As we discussed at LPC, RV wouldn't help with not annotated functions because
you'd need to add tracepoints there, so probably the best is to just add a
might_sleep and be done with it.

Other than that, I double checked and CONFIG_DEBUG_ATOMIC_SLEEP is in fact
disabled on non-debug kernels in Fedora/RHEL (and I presume also in Debian and
friends), so the other concern you raised is indeed valid.

Although perhaps rather unlikely, I'm not sure we can completely rule out cases
in which non-debug kernel (where several other debugging features besides
CONFIG_DEBUG_ATOMIC_SLEEP are disabled) behave differently enough for some bugs,
otherwise invisible on debug kernels, to pop up.

Another use could be debugging kernel modules on non-debug kernels, perhaps to
avoid some other debug features to be present while still relying on the
packaged kernel.

For this to work you'd need to add a tracepoint on might_sleep when
CONFIG_DEBUG_ATOMIC_SLEEP is disabled (and it's currently a NOP), hopefully that
wouldn't make people too angry.

Again, none of this would be ground-breaking but it doesn't look useless either.

Any thoughts?

Thanks,
Gabriele