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: <c966b103b002e520f5a4bf80b18835a485cf0cfa.camel@redhat.com>
Date: Tue, 23 Dec 2025 16:21:16 +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

Hi Yunseong,

> I will also double-check sleepable memory allocations in the context of
> PREEMPT_RT kernels to see if there are other patterns being missed.

You may want to play with lockdep as well, it's much heavier but can catch a lot
of those issues. I believe it still relies on annotations though, so it might
have blind spots too (though it's battle-tested on locks).

> My interest in this arose because I've been seeing these legacy patterns
> consistently reported as bugs in the Real-Time (PREEMPT_RT) kernel. It
> seems many kernel developers are still unaware that these patterns are
> problematic, partly because some older Linux learning materials actually
> recommended them. This makes it quite likely that such code will continue
> to find its way into the upstream.

Yeah that's quite common indeed, I see kernel functions claiming to be atomic
while in fact using (sleeping) spinlocks.

Reading the material Daniel left (RV's original author), he thought of a similar
model, so at least we know there was interest in this kind of thing.


> I will keep looking into more meaningful contributions for RV. For instance,
> I’ve been considering a monitor to detect excessive memory compaction issues
> under specific workloads, which I’ve encountered during kernel development.

Looking forward to knowing more!

Cheers,
Gabriele