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

[Nam Cao <namcao@linutronix.de>]

Yunseong Kim <ysk@kzalloc.com> writes:
> Hi Nam,
>
> I've been very interested in RV (Runtime Verification)

Cool, happy to learn you find it interesting.

> to proactively detect
> "sleep in atomic" scenarios on PREEMPT_RT kernels. Specifically, I'm looking
> for ways to find cases where sleeping spinlocks or memory allocations are used
> within preemption-disabled or irq-disabled contexts. While searching for
> solutions, I discovered the RV subsystem.
...
> Here are my questions:
>
> 1. Does the rtapp:sleep monitor proactively detect scenarios that
>    could lead to sleeping in atomic context, perhaps before
>    CONFIG_DEBUG_ATOMIC_SLEEP (enabled) would trigger at the actual point of
>    sleeping?

No it does not, as explained by Gabriele.

I am a bit confused, because CONFIG_DEBUG_ATOMIC_SLEEP seems to already
do what you need. CONFIG_DEBUG_ATOMIC_SLEEP does warn before the actual
point of sleeping. Sleeping locks and memory allocations are marked with
might_sleep(). When they are called in atomic context, we have a warning
regardless of whether actual sleep happens. See the comment above
might_sleep():

"This is a useful debugging help to be able to catch problems early and
not be bitten later when the calling function happens to sleep when it
is not supposed to"

For sure you can implement this functionality in RV, but I don't think
RV can do more. An advantage of doing it in RV is the ability to toggle
at run-time, but that's a different discussion.

> 2. Is there a way to enable this monitor (e.g., rtapp:sleep)
>    immediately as soon as the RV subsystem is loaded during boot time?
>    (How to make this "default turn on"?)

At the moment, no. But if you need this, we could look into implementing it.

> 3. When a "violation detected" message occurs at runtime, is it
>    possible to get a call stack of the location that triggered the
>    violation? The panic reactor provides a full stack, but I'm
>    wondering if this is also possible with the printk reactor.

You can use monitor's tracepoint to get the stacktrace, as mentioned by Gabriele.

> This led me to research ways to find these issues proactively at a
> static analysis level, and I created some regex and coccinelle scripts
> to detect them.
...
> Tomas, the author of the rtlockscope project, also gave me some deep
> insights into this static analysis approach.

RV is not a static checker, it is a run-time checker.

Just in case you are not aware yet, there is also Smatch:
https://github.com/error27/smatch. But I can't offer much help there.

Nam