[0/3] tracing/user_events: Allow events to persist for perfmon_capable users

Message

Beau Belgrave Sept. 1, 2023, 8:43 p.m. UTC

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.

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              | 28 +++++-----
 .../testing/selftests/user_events/abi_test.c  | 55 ++++++++++++++++++-
 .../testing/selftests/user_events/dyn_test.c  | 54 +++++++++++++++++-
 5 files changed, 149 insertions(+), 20 deletions(-)


base-commit: f940e482b0f889e697372a22b6c15da87aa1f63a

Comments

Steven Rostedt Sept. 1, 2023, 8:57 p.m. UTC | #1

Hi Beau,

Just an FYI, except for fixes, it is never a good ideal to send out patches
while the merge window is open. They will likely be ignored for the
entirety of the merge window.

-- Steve


On Fri,  1 Sep 2023 20:43:29 +0000
Beau Belgrave <[e-mail]> wrote:

> 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.
> 
> 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              | 28 +++++-----
>  .../testing/selftests/user_events/abi_test.c  | 55 ++++++++++++++++++-
>  .../testing/selftests/user_events/dyn_test.c  | 54 +++++++++++++++++-
>  5 files changed, 149 insertions(+), 20 deletions(-)
> 
> 
> base-commit: f940e482b0f889e697372a22b6c15da87aa1f63a