On Tue, 2026-05-19 at 09:49 +0200, Nam Cao wrote: > Add a wakeup monitor to detect a lower-priority task waking up a > higher-priority task. > > The rtapp/sleep monitor already detects this. However, that monitor > triggers an error in the context of the woken task and user only gets the > stacktrace of that task. It is also extremely useful to get the stacktrace > of the waking task, which this monitor offers. In other words, this monitor > complements the rtapp/sleep monitor. > > Signed-off-by: Nam Cao <[email protected]>
Looks neat, so the idea here is that we are looking at the same events sleep would react for, just from a different perspective, so it does make sense to run them both together. You may want to set depends on RV_PER_TASK_MONITORS >= 3 in rtapp/Kconfig. Though if we plan to add more per-task monitors we may need to find a better solution. > diff --git a/tools/verification/models/rtapp/wakeup.ltl > b/tools/verification/models/rtapp/wakeup.ltl > new file mode 100644 > index 000000000000..a5d63ca0811a > --- /dev/null > +++ b/tools/verification/models/rtapp/wakeup.ltl > @@ -0,0 +1,5 @@ > +RULE = always (((RT and USER_THREAD) imply > + (not (WOKEN_BY_LOWER_PRIO or WOKEN_BY_SOFTIRQ)) or > ALLOWLIST)) > + > +ALLOWLIST = BLOCK_ON_RT_MUTEX > + or FUTEX_LOCK_PI So here the events and atoms are similar to the ones in sleep, but since we fail on the waking event, we are going to see it from the perspective of the waker task, right? But are those really equivalent? Why do we do RT and USER_THREAD here while there is a much more nuanced set of conditions in sleep? If I understand it correctly, sleep can monitor some kernel threads but this monitor does not, is there a reason for that? Are we just not interested in the waker for kernel threads? > diff --git a/kernel/trace/rv/monitors/wakeup/Kconfig > b/kernel/trace/rv/monitors/wakeup/Kconfig > new file mode 100644 > index 000000000000..3cf11c5cd5f7 > --- /dev/null > +++ b/kernel/trace/rv/monitors/wakeup/Kconfig > @@ -0,0 +1,17 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +config RV_MON_WAKEUP > + depends on RV > + depends on RV_MON_RTAPP > + depends on HAVE_SYSCALL_TRACEPOINTS > + select TRACE_IRQFLAGS > + default y > + select LTL_MON_EVENTS_ID > + bool "wakeup monitor" > + help > + This monitor detects a lower-priority task waking up a > + higher-priority task. The RV_MON_SLEEP monitor already > + detects this case, but this monitor detects in the context > + of the waking task instead. This and RV_MON_SLEEP can be > + enabled together to get the stacktrace of both the waking > + task and the woken task. I'm not sure if there is any better terminology, but "waking" task makes me think of the task that is about to be woken, though it can mean also that task that is waking another (what you probably mean here). What about using the waker/wakee terminology? I see the kernel (events/sched.h) uses waking as well, but it says waking context (which a bit clearer to me than waking task). May be worth running it through an LLM which can produce more English-native unambiguous wording, or maybe I'm just flipping.. Also please document it in Documentation/trace/rv/monitor_rtapp.rst Thanks, Gabriele
