From: Beau Belgrave <beaub@linux.microsoft.com>
To: rostedt@goodmis.org, mhiramat@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
ast@kernel.org, dcook@linux.microsoft.com
Subject: [PATCH v2 0/3] tracing/user_events: Allow events to persist for perfmon_capable users
Date: Tue, 12 Sep 2023 18:07:01 +0000 [thread overview]
Message-ID: <20230912180704.1284-1-beaub@linux.microsoft.com> (raw)
There are several scenarios that have come up where having a user_event
persist even if the process that registered it exits. The main one is
having a daemon create events on bootup that shouldn't get deleted if
the daemon has to exit or reload. Another is within OpenTelemetry
exporters, they wish to potentially check if a user_event exists on the
system to determine if exporting the data out should occur. The
user_event in this case must exist even in the absence of the owning
process running (such as the above daemon case).
Since persistent events aren't automatically cleaned up, we want to ensure
only trusted users are allowed to do this. It seems reasonable to use
CAP_PERFMON as that boundary, since those users can already do many things
via perf_event_open without requiring full CAP_SYS_ADMIN.
This patchset brings back the ability to use /sys/kernel/tracing/dynamic_events
to create user_events, as persist is now back to being supported. Both the
register and delete of events that persist require CAP_PERFMON, which prevents
a non-perfmon user from making an event go away that a perfmon user decided
should persist.
Change History:
V2:
Added common user_event_capable() function to check access given
the register flags.
Ensure access check is done for dynamic_events when implicitly removing
events, such as "echo 'u:test' > /sys/kernel/tracing/dynamic_events".
Beau Belgrave (3):
tracing/user_events: Allow events to persist for perfmon_capable users
selftests/user_events: Test persist flag cases
tracing/user_events: Document persist event flags
Documentation/trace/user_events.rst | 21 ++++++-
include/uapi/linux/user_events.h | 11 +++-
kernel/trace/trace_events_user.c | 36 +++++++-----
.../testing/selftests/user_events/abi_test.c | 55 ++++++++++++++++++-
.../testing/selftests/user_events/dyn_test.c | 54 +++++++++++++++++-
5 files changed, 157 insertions(+), 20 deletions(-)
base-commit: fc1653abba0d554aad80224e51bcad42b09895ed
--
2.34.1
next reply other threads:[~2023-09-12 18:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 18:07 Beau Belgrave [this message]
2023-09-12 18:07 ` [PATCH v2 1/3] tracing/user_events: Allow events to persist for perfmon_capable users Beau Belgrave
2023-09-12 18:07 ` [PATCH v2 2/3] selftests/user_events: Test persist flag cases Beau Belgrave
2023-09-12 18:07 ` [PATCH v2 3/3] tracing/user_events: Document persist event flags Beau Belgrave
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=20230912180704.1284-1-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=ast@kernel.org \
--cc=dcook@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--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