diff options
| author | CaoRuichuang <create0818@163.com> | 2026-04-07 00:24:34 +0800 |
|---|---|---|
| committer | Steven Rostedt (Google) <rostedt@goodmis.org> | 2026-04-08 16:26:22 -0400 |
| commit | 0ec6be95351b00ca95b39e8f0c6bbe0a9615f990 (patch) | |
| tree | f2297f683db75adc3e12e0bdce27810b25584bb0 /scripts/stackusage | |
| parent | 8053f49fed581c40fcc87fa54904f4fa473f46b7 (diff) | |
tracing: Report ipi_raise target CPUs as cpumask
Bugzilla 217447 points out that ftrace bitmask fields still use the
legacy dynamic-array format, which makes trace consumers treat them
as unsigned long arrays instead of bitmaps.
This is visible in the ipi events today: ipi_send_cpumask already
reports its CPU mask as '__data_loc cpumask_t', but ipi_raise still
exposes target_cpus as '__data_loc unsigned long[]'.
Switch ipi_raise to __cpumask() and the matching helpers so its
tracefs format matches the existing cpumask representation used by
the other ipi event. The underlying storage size stays the same, but
trace data consumers can now recognize the field as a cpumask
directly.
Link: https://patch.msgid.link/20260406162434.40767-1-create0818@163.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217447
Signed-off-by: CaoRuichuang <create0818@163.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
