mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Nam Cao <namcao@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org,
	 linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] rv/rtapp/sleep: Make the error more informative for user
Date: Tue, 19 May 2026 17:07:59 +0200	[thread overview]
Message-ID: <19cffa1267c6538e6310b0149b0367807af76ac0.camel@redhat.com> (raw)
In-Reply-To: <14242f444f7d2396c0c5a345f0099665d09a0ec5.1779176466.git.namcao@linutronix.de>

On Tue, 2026-05-19 at 09:49 +0200, Nam Cao wrote:
> The rtapp/sleep monitor detects real-time tasks which go to sleep in an
> real-time-unsafe manner. If this happen, the monitor triggers a trace event
> in the sched_wakeup tracepoint's handler.
> 

Ok so here WAKE is no longer tied to the wakeup event but to the end of the task
switch.

So what happens if a task was not sleeping but just got preempted? Wouldn't that
trigger WAKE (though that isn't a real wakeup) without RT_FRIENDLY_WAKE ?

Thanks,
Gabriele

> However, the invoking context of that trace event is not the most
> informative, because of the stack trace of that event is the wakeup's code
> path which is not very helpful:
> 
> 74.669317: rv:error_sleep: condvar[254]: violation detected
>     ltl_validate+0x345 ([kernel.kallsyms])
>     handle_sched_wakeup+0x34 ([kernel.kallsyms])
>     ttwu_do_activate+0xff ([kernel.kallsyms])
>     sched_ttwu_pending+0x104 ([kernel.kallsyms])
>     __flush_smp_call_function_queue+0x15b ([kernel.kallsyms])
>     __sysvec_call_function_single+0x18 ([kernel.kallsyms])
>     sysvec_call_function_single+0x66 ([kernel.kallsyms])
>     asm_sysvec_call_function_single+0x1a ([kernel.kallsyms])
>     pv_native_safe_halt+0xf ([kernel.kallsyms])
>     default_idle+0x9 ([kernel.kallsyms])
>     default_idle_call+0x33 ([kernel.kallsyms])
>     do_idle+0x234 ([kernel.kallsyms])
>     cpu_startup_entry+0x24 ([kernel.kallsyms])
>     start_secondary+0xf8 ([kernel.kallsyms])
>     common_startup_64+0x13e ([kernel.kallsyms])
> 
> What would be much more valuable is the stack trace of the task itself.
> 
> Change the update of WAKEUP from being in sched_wakeup trace point's
> handler to sched_exit trace point's handler. This makes the event happen in
> the task's context, making the stack trace far more informative for user:
> 
> rv:error_sleep: condvar[254]: violation detected
>     ltl_validate+0x345 ([kernel.kallsyms])
>     handle_sched_exit+0x39 ([kernel.kallsyms])
>     __schedule+0x80f ([kernel.kallsyms])
>     schedule+0x22 ([kernel.kallsyms])
>     futex_do_wait+0x33 ([kernel.kallsyms])
>     __futex_wait+0x8c ([kernel.kallsyms])
>     futex_wait+0x73 ([kernel.kallsyms])
>     do_futex+0xc6 ([kernel.kallsyms])
>     __x64_sys_futex+0x121 ([kernel.kallsyms])
>     do_syscall_64+0xf3 ([kernel.kallsyms])
>     entry_SYSCALL_64_after_hwframe+0x77 ([kernel.kallsyms])
>     __futex_abstimed_wait_common64+0xc6 (inlined)
>     __futex_abstimed_wait_common+0xc6 (/usr/lib/x86_64-linux-gnu/libc.so.6)
> 
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
>  kernel/trace/rv/monitors/sleep/sleep.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/trace/rv/monitors/sleep/sleep.c
> b/kernel/trace/rv/monitors/sleep/sleep.c
> index 8dfe5ec13e19..0a36f5519e6b 100644
> --- a/kernel/trace/rv/monitors/sleep/sleep.c
> +++ b/kernel/trace/rv/monitors/sleep/sleep.c
> @@ -92,9 +92,9 @@ static void handle_sched_set_state(void *data, struct
> task_struct *task, int sta
>  		ltl_atom_pulse(task, LTL_ABORT_SLEEP, true);
>  }
>  
> -static void handle_sched_wakeup(void *data, struct task_struct *task)
> +static void handle_sched_exit(void *data, bool is_switch)
>  {
> -	ltl_atom_pulse(task, LTL_WAKE, true);
> +	ltl_atom_pulse(current, LTL_WAKE, true);
>  }
>  
>  static void handle_sched_waking(void *data, struct task_struct *task)
> @@ -200,7 +200,7 @@ static int enable_sleep(void)
>  		return retval;
>  
>  	rv_attach_trace_probe("rtapp_sleep", sched_waking,
> handle_sched_waking);
> -	rv_attach_trace_probe("rtapp_sleep", sched_wakeup,
> handle_sched_wakeup);
> +	rv_attach_trace_probe("rtapp_sleep", sched_exit_tp,
> handle_sched_exit);
>  	rv_attach_trace_probe("rtapp_sleep", sched_set_state_tp,
> handle_sched_set_state);
>  	rv_attach_trace_probe("rtapp_sleep", contention_begin,
> handle_contention_begin);
>  	rv_attach_trace_probe("rtapp_sleep", contention_end,
> handle_contention_end);
> @@ -213,7 +213,7 @@ static int enable_sleep(void)
>  static void disable_sleep(void)
>  {
>  	rv_detach_trace_probe("rtapp_sleep", sched_waking,
> handle_sched_waking);
> -	rv_detach_trace_probe("rtapp_sleep", sched_wakeup,
> handle_sched_wakeup);
> +	rv_detach_trace_probe("rtapp_sleep", sched_exit_tp,
> handle_sched_exit);
>  	rv_detach_trace_probe("rtapp_sleep", sched_set_state_tp,
> handle_sched_set_state);
>  	rv_detach_trace_probe("rtapp_sleep", contention_begin,
> handle_contention_begin);
>  	rv_detach_trace_probe("rtapp_sleep", contention_end,
> handle_contention_end);


  reply	other threads:[~2026-05-19 15:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  7:49 [PATCH 0/3] rv: rtapp monitor update Nam Cao
2026-05-19  7:49 ` [PATCH 1/3] rv/rtapp/sleep: Make the error more informative for user Nam Cao
2026-05-19 15:07   ` Gabriele Monaco [this message]
2026-05-19 15:24     ` Nam Cao
2026-05-19 15:26       ` Gabriele Monaco
2026-05-19  7:49 ` [PATCH 2/3] rv/rtapp/sleep: Update nanosleep rule Nam Cao
2026-05-19 12:58   ` Gabriele Monaco
2026-05-19 14:51     ` Nam Cao
2026-05-21  7:04   ` Gabriele Monaco
2026-05-25 11:38     ` Nam Cao
2026-05-19  7:49 ` [PATCH 3/3] rv/rtapp: Add wakeup monitor Nam Cao
2026-05-21  6:40   ` Gabriele Monaco
2026-05-25 11:45     ` Nam Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19cffa1267c6538e6310b0149b0367807af76ac0.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=namcao@linutronix.de \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®