linux-kernel - [RFC PATCH 0/3] report task state in symbolic chars in sched tracepoints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230725072254.32045-1-zegao@tencent.com>
Date:   Tue, 25 Jul 2023 15:22:51 +0800
From:   Ze Gao <zegao2021@...il.com>
To:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, Ze Gao <zegao@...cent.com>
Subject: [RFC PATCH 0/3] report task state in symbolic chars in sched tracepoints

In the status quo, we should see three different outcomes of the reported
sched-out task state from perf-script, perf-sched-timehist, and Tp_printk
of tracepoint sched_switch.  And it's not hard to figure out that the
former two are built upon the third one, and the reason why we see this
inconsistency is that the former two does not catch up with the internal
change of reported task state definitions as the kernel evolves.

IMHO, exporting internal representations of task state in the tracepoint
sched_switch is not a good practice and not encouraged at all, which can
easily break userspace tools that relies on it. Especially when tracepoints
are massively used in many observability tools nowadays due to its stable
nature, which makes them no longer used for debug only purpose and we
should be careful to decide what ought to be reported to userspace and what
ought not.

Therefore, to fix the issues mentioned above for good, instead of choosing
to sync the userspace tracing tools with the latest task states constants
mapping, I proposed to replace reported task state in sched_switch with
a symbolic character, and save the further processing of userspace tools
and spare them from knowing further implementation details in the kernel.

After this patch seires, we report 'RSDTtXZPI' the same as in procfs, plus
a 'p' which denotes PREEMP_ACTIVE and is used for sched_switch tracepoint only.

Reviews welcome!

Regards,

Ze

Ze Gao (2):
  sched, tracing: report task state in symbolic chars instead
  perf sched: sync with latest sched_switch tracepoint definition

 include/trace/events/sched.h | 41 ++++++++++-----------------
 tools/perf/builtin-sched.c   | 55 ++++++------------------------------
 2 files changed, 24 insertions(+), 72 deletions(-)

Ze Gao (1):
  libtraceevent: sync with latest sched_switch tracepoint definition

 plugins/plugin_sched_switch.c | 23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

-- 
2.40.1