Message-ID: <92a7c013-0676-4c81-867f-b55c69a1edd6@kzalloc.com>
Date: Tue, 23 Dec 2025 23:31:54 +0900
From: Yunseong Kim <ysk@...lloc.com>
To: Gabriele Monaco <gmonaco@...hat.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 Gabriele,

Thanks for the follow-up and for taking the time to double-check the
configuration details.

On 12/22/25 4:40 PM, Gabriele Monaco wrote:
> 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.

Thanks for your insight! I agree that for unannotated functions, adding
might_sleep() directly is the most straightforward approach.

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

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

I agree that CONFIG_DEBUG_ATOMIC_SLEEP covers most cases, but as you
pointed out, the fact that it's disabled in production kernels (Fedora,
RHEL, Debian, Ubuntu etc.) gives this approach real-world value. I was
hesitant about whether this was worth a contribution, so I truly appreciate
your encouraging feedback.

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

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.

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

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.

> Thanks,
> Gabriele

It was a great pleasure discussing these ideas with you and Nam. I sorry
for any lack of clarity in my previous explanations during LPC 25.

Thanks again for your insights! :)

Best regards,
Yunseong

Powered by blists - more mailing lists