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

[Gabriele Monaco <gmonaco@redhat.com>]

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