From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-perf-users@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michael Petlan <mpetlan@redhat.com>,
Veronika Molnarova <vmolnaro@redhat.com>,
Suren Baghdasaryan <surenb@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH v2 0/2] tracing: gfp: Fix regression of printing GFP flags in user space tracing tooling
Date: Thu, 16 Jan 2025 16:41:23 -0500 [thread overview]
Message-ID: <20250116214123.917928229@goodmis.org> (raw)
This fixes a regression that was brought up last year[1], but due
to missing a response it was forgotten about.
The commit 772dd0342727c ("mm: enumerate all gfp flags") introduced
usage of enums in creating of the __GFP_* flags. But enums are not
converted to their values like macros are in the trace event format
files that are exported to user space to allow tools to properly parse
the raw binary events. This broke the parsing of gfp flags.
Instead of having something like:
gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP
It would just have a raw hex value:
gfp_flags=0x140cca
Which is mostly useless or hard to decipher.
Instead of reverting the enums into macros, use the TRACE_DEFINE_ENUM()
macro that informs the tracing subsystem about enums and it converts them
to their proper values.
The first patch is a fix that fixes the regression and should go into
the current rc release as well as be backported to stable.
The second patch is a clean up that removes duplication of the GFP flags
in the macros of mmflags.h and should be added in the coming merge window.
I kept the two together so that one can see why the solution to the first
patch was made. The use of TRACE_GFP_EM() internally was added to make
it easier to reuse the TRACE_GFP_FLAGS macro.
Changes since v1: https://lore.kernel.org/20250116132359.1f20cdec@gandalf.local.home
- Moved the updates to only include/trace/events/mmflags.h
- Removed the macro call in include/trace/events/kmem.h
- Use an internal TRACE_GFP_EM() macro in TRACE_GFP_FLAGS to allow
it to be expanded later for use with the __def_gfpflags_names()
macro
- Added the second non critical patch to show he clean up of removing
duplicate defines of the ___GFP_*_BITs.
[1] https://lore.kernel.org/all/87be5f7c-1a0-dad-daa0-54e342efaea7@redhat.com/
Steven Rostedt (2):
tracing: gfp: Fix the GFP enum values shown for user space tracing tools
tracing: gfp: Remove duplication of recording GFP flags
----
include/trace/events/mmflags.h | 104 +++++++++++++++++++++++++++++------------
1 file changed, 73 insertions(+), 31 deletions(-)
next reply other threads:[~2025-01-16 21:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 21:41 Steven Rostedt [this message]
2025-01-16 21:41 ` [PATCH v2 1/2] tracing: gfp: Fix the GFP enum values shown for user space tracing tools Steven Rostedt
2025-01-16 21:41 ` [PATCH v2 2/2] tracing: gfp: Remove duplication of recording GFP flags Steven Rostedt
2025-01-16 21:48 ` [PATCH v2 0/2] tracing: gfp: Fix regression of printing GFP flags in user space tracing tooling Steven Rostedt
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=20250116214123.917928229@goodmis.org \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mpetlan@redhat.com \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vmolnaro@redhat.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