[0/5] tracing/user_events: Add auto-del flag for events

Message ID 20230530235304.2726-1-beaub@linux.microsoft.com
Headers
Series tracing/user_events: Add auto-del flag for events |

Message

Beau Belgrave May 30, 2023, 11:52 p.m. UTC
  As part of the discussions for user_events aligning to be used with eBPF
it became clear [1] we needed a way to delete events without having to rely
upon the delete IOCTL. Steven suggested that we simply have an owner
for the event, however, the event can be held by more than just the
first register FD, such as perf/ftrace or additional registers. In order
to handle all those cases, we must only delete after all references are
gone from both user and kernel space.

This series adds a new register flag, USER_EVENT_REG_AUTO_DEL, which
causes the event to delete itself upon the last put reference. We cannot
fully drop the delete IOCTL, since we still want to enable events to be
registered early via dynamic_events and persist. If the auto delete flag
was used during dynamic_events, the event would delete immediately.

We have a few key events that we enable immediately after boot and are
monitored in our environments. Today this is done via dynamic events,
however, it could also be done directly via the ABI by not passing the
auto delete flag.

NOTE: I'll need to merge this work once we take these [2] [3] patches
into for-next. I'm happy to do so once they land there.

1: https://lore.kernel.org/linux-trace-kernel/20230518093600.3f119d68@rorschach.local.home/
2: https://lore.kernel.org/linux-trace-kernel/20230529032100.286534-1-sunliming@kylinos.cn/
3: https://lore.kernel.org/linux-trace-kernel/20230519230741.669-1-beaub@linux.microsoft.com/

Beau Belgrave (5):
  tracing/user_events: Store register flags on events
  tracing/user_events: Track refcount consistently via put/get
  tracing/user_events: Add flag to auto-delete events
  tracing/user_events: Add self-test for auto-del flag
  tracing/user_events: Add auto-del flag documentation

 Documentation/trace/user_events.rst           |  21 +-
 include/uapi/linux/user_events.h              |  10 +-
 kernel/trace/trace_events_user.c              | 183 ++++++++++++++----
 .../testing/selftests/user_events/abi_test.c  | 115 ++++++++++-
 4 files changed, 278 insertions(+), 51 deletions(-)


base-commit: 3862f86c1529fa0016de6344eb974877b4cd3838
  

Comments

Alexei Starovoitov May 31, 2023, 9:44 p.m. UTC | #1
On Tue, May 30, 2023 at 04:52:59PM -0700, Beau Belgrave wrote:
> As part of the discussions for user_events aligning to be used with eBPF
> it became clear [1] we needed a way to delete events without having to rely
> upon the delete IOCTL. Steven suggested that we simply have an owner

This patch set is not addressing the issues I pointed out earlier.
It adds a new flag and new api. It's not a fix.

> for the event, however, the event can be held by more than just the
> first register FD, such as perf/ftrace or additional registers. In order
> to handle all those cases, we must only delete after all references are
> gone from both user and kernel space.
> 
> This series adds a new register flag, USER_EVENT_REG_AUTO_DEL, which
> causes the event to delete itself upon the last put reference. We cannot

Do not introduce a new flag. Make this default.

> fully drop the delete IOCTL, since we still want to enable events to be
> registered early via dynamic_events and persist. If the auto delete flag
> was used during dynamic_events, the event would delete immediately.

You have to delete this broken "delete via ioctl" api.
For persistent events you need a different api in its own name scope,
so it doesn't conflict with per-fd events.

> We have a few key events that we enable immediately after boot and are
> monitored in our environments. Today this is done via dynamic events,
> however, it could also be done directly via the ABI by not passing the
> auto delete flag.
>
> NOTE: I'll need to merge this work once we take these [2] [3] patches
> into for-next. I'm happy to do so once they land there.
> 
> 1: https://lore.kernel.org/linux-trace-kernel/20230518093600.3f119d68@rorschach.local.home/
> 2: https://lore.kernel.org/linux-trace-kernel/20230529032100.286534-1-sunliming@kylinos.cn/
> 3: https://lore.kernel.org/linux-trace-kernel/20230519230741.669-1-beaub@linux.microsoft.com/
> 
> Beau Belgrave (5):
>   tracing/user_events: Store register flags on events
>   tracing/user_events: Track refcount consistently via put/get
>   tracing/user_events: Add flag to auto-delete events
>   tracing/user_events: Add self-test for auto-del flag
>   tracing/user_events: Add auto-del flag documentation
> 
>  Documentation/trace/user_events.rst           |  21 +-
>  include/uapi/linux/user_events.h              |  10 +-
>  kernel/trace/trace_events_user.c              | 183 ++++++++++++++----
>  .../testing/selftests/user_events/abi_test.c  | 115 ++++++++++-
>  4 files changed, 278 insertions(+), 51 deletions(-)
> 
> 
> base-commit: 3862f86c1529fa0016de6344eb974877b4cd3838
> -- 
> 2.25.1
>
  
Beau Belgrave June 1, 2023, 12:29 a.m. UTC | #2
On Wed, May 31, 2023 at 02:44:44PM -0700, Alexei Starovoitov wrote:
> On Tue, May 30, 2023 at 04:52:59PM -0700, Beau Belgrave wrote:
> > As part of the discussions for user_events aligning to be used with eBPF
> > it became clear [1] we needed a way to delete events without having to rely
> > upon the delete IOCTL. Steven suggested that we simply have an owner
> 
> This patch set is not addressing the issues I pointed out earlier.
> It adds a new flag and new api. It's not a fix.
> 

Can you point out the scenario you are worried about?

For example, if anything is using a per-FD event, it cannot be deleted,
it will return -EBUSY. If perf, ftrace, or any user-process still has a
reference to the event, the delete will not go through (even without
these changes).

I read your previous issues as, we cannot let anyone delete events while
others are using them. And I also heard Steven state, we need to not let
things pile up, since manual deletes are unlikely.

> > for the event, however, the event can be held by more than just the
> > first register FD, such as perf/ftrace or additional registers. In order
> > to handle all those cases, we must only delete after all references are
> > gone from both user and kernel space.
> > 
> > This series adds a new register flag, USER_EVENT_REG_AUTO_DEL, which
> > causes the event to delete itself upon the last put reference. We cannot
> 
> Do not introduce a new flag. Make this default.
> 

If this is to be default, then I would have to have a flag for
persistent events, which seems reasonable.

> > fully drop the delete IOCTL, since we still want to enable events to be
> > registered early via dynamic_events and persist. If the auto delete flag
> > was used during dynamic_events, the event would delete immediately.
> 
> You have to delete this broken "delete via ioctl" api.
> For persistent events you need a different api in its own name scope,
> so it doesn't conflict with per-fd events.
> 

We have certain events we want persistent, that don't go away if the
process crashes, etc. and we don't yet have a ring buffer up via
perf_events.

In these cases, we want the name to be the same for all processes, since
it's a common event. An example is a common library that emits out
assert messages. We want to watch for any asserts on the system,
regardless of which process emits them.

I'm not sure I understand how you think they would conflict?

Another process cannot come in and register the same event name while
it's in use. They can only do so once everything has been closed down.

If another process uses the same name for an event, it must match the
previous events arguments, and is treated as the same event. If they
don't match then the register fails. The only way to get a conflict is
to delete the event and then create a new one, but that only works if
no one is still using it at all.

Thanks,
-Beau

> > We have a few key events that we enable immediately after boot and are
> > monitored in our environments. Today this is done via dynamic events,
> > however, it could also be done directly via the ABI by not passing the
> > auto delete flag.
> >
> > NOTE: I'll need to merge this work once we take these [2] [3] patches
> > into for-next. I'm happy to do so once they land there.
> > 
> > 1: https://lore.kernel.org/linux-trace-kernel/20230518093600.3f119d68@rorschach.local.home/
> > 2: https://lore.kernel.org/linux-trace-kernel/20230529032100.286534-1-sunliming@kylinos.cn/
> > 3: https://lore.kernel.org/linux-trace-kernel/20230519230741.669-1-beaub@linux.microsoft.com/
> > 
> > Beau Belgrave (5):
> >   tracing/user_events: Store register flags on events
> >   tracing/user_events: Track refcount consistently via put/get
> >   tracing/user_events: Add flag to auto-delete events
> >   tracing/user_events: Add self-test for auto-del flag
> >   tracing/user_events: Add auto-del flag documentation
> > 
> >  Documentation/trace/user_events.rst           |  21 +-
> >  include/uapi/linux/user_events.h              |  10 +-
> >  kernel/trace/trace_events_user.c              | 183 ++++++++++++++----
> >  .../testing/selftests/user_events/abi_test.c  | 115 ++++++++++-
> >  4 files changed, 278 insertions(+), 51 deletions(-)
> > 
> > 
> > base-commit: 3862f86c1529fa0016de6344eb974877b4cd3838
> > -- 
> > 2.25.1
> >