lttng-dev Archive mirror
 help / color / mirror / Atom feed
From: Bruce Ashfield via lttng-dev <lttng-dev@lists.lttng.org>
To: lttng-dev@lists.lttng.org
Subject: [lttng-dev] [PATCH] sched/tracing: fix __trace_sched_switch_state (5.18-rc7+)
Date: Thu, 19 May 2022 11:02:57 -0400	[thread overview]
Message-ID: <20220519150257.26136-1-bruce.ashfield@gmail.com> (raw)

From: Bruce Ashfield <bruce.ashfield@gmail.com>

The commit [fix: sched/tracing: Don't re-read p->state when emitting
sched_switch event (v5.18)] was correct, but the kernel changed their
mind with the following commit:

   commit 9c2136be0878c88c53dea26943ce40bb03ad8d8d
   Author: Delyan Kratunov <delyank@fb.com>
   Date:   Wed May 11 18:28:36 2022 +0000

       sched/tracing: Append prev_state to tp args instead

       Commit fa2c3254d7cf (sched/tracing: Don't re-read p->state when emitting
       sched_switch event, 2022-01-20) added a new prev_state argument to the
       sched_switch tracepoint, before the prev task_struct pointer.

       This reordering of arguments broke BPF programs that use the raw
       tracepoint (e.g. tp_btf programs). The type of the second argument has
       changed and existing programs that assume a task_struct* argument
       (e.g. for bpf_task_storage access) will now fail to verify.

       If we instead append the new argument to the end, all existing programs
       would continue to work and can conditionally extract the prev_state
       argument on supported kernel versions.

       Fixes: fa2c3254d7cf (sched/tracing: Don't re-read p->state when emitting sched_switch event, 2022-01-20)
       Signed-off-by: Delyan Kratunov <delyank@fb.com>
       Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
       Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
       Link: https://lkml.kernel.org/r/c8a6930dfdd58a4a5755fc01732675472979732b.camel@fb.com

By reordering the parameters (again) we can get back up and building.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---

Hi all,

This is more than likely NOT a correct fix, but while working on the
yocto -dev reference kernel, I ran into this build failure against
5.18-rc7.

I didn't see any sign of another fix on the mailing list, so I wanted
to send this in case anyone else runs into the failure and to check
to see if there's a better fix in progress.

Cheers,

Bruce


 include/instrumentation/events/sched.h | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/instrumentation/events/sched.h b/include/instrumentation/events/sched.h
index 339bec9..f9e9c38 100644
--- a/include/instrumentation/events/sched.h
+++ b/include/instrumentation/events/sched.h
@@ -23,8 +23,9 @@
 #if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(5,18,0))
 
 static inline long __trace_sched_switch_state(bool preempt,
-		unsigned int prev_state,
-		struct task_struct *p)
+		struct task_struct *p,
+		struct task_struct *n,
+		unsigned int prev_state )
 {
         unsigned int state;
 
@@ -356,20 +357,20 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(sched_wakeup_template, sched_wakeup_new,
 LTTNG_TRACEPOINT_EVENT(sched_switch,
 
 	TP_PROTO(bool preempt,
-		unsigned int prev_state,
 		struct task_struct *prev,
-		struct task_struct *next),
+		struct task_struct *next,
+		unsigned int prev_state),
 
-	TP_ARGS(preempt, prev_state, prev, next),
+	TP_ARGS(preempt, prev, next, prev_state),
 
 	TP_FIELDS(
 		ctf_array_text(char, prev_comm,	prev->comm, TASK_COMM_LEN)
 		ctf_integer(pid_t, prev_tid, prev->pid)
 		ctf_integer(int, prev_prio, prev->prio - MAX_RT_PRIO)
 #ifdef CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM
-		ctf_enum(task_state, long, prev_state, __trace_sched_switch_state(preempt, prev_state, prev))
+		ctf_enum(task_state, long, prev_state, __trace_sched_switch_state(preempt, prev, next, prev_state))
 #else
-		ctf_integer(long, prev_state, __trace_sched_switch_state(preempt, prev_state, prev))
+		ctf_integer(long, prev_state, __trace_sched_switch_state(preempt, prev, next, prev_state))
 #endif
 		ctf_array_text(char, next_comm, next->comm, TASK_COMM_LEN)
 		ctf_integer(pid_t, next_tid, next->pid)
-- 
2.19.1

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

             reply	other threads:[~2022-05-19 15:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 15:02 Bruce Ashfield via lttng-dev [this message]
2022-05-19 15:31 ` [lttng-dev] [PATCH] sched/tracing: fix __trace_sched_switch_state (5.18-rc7+) Mathieu Desnoyers via lttng-dev
2022-05-19 16:01   ` Bruce Ashfield via lttng-dev

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=20220519150257.26136-1-bruce.ashfield@gmail.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=bruce.ashfield@gmail.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).