Message ID | 20230530235304.2726-1-beaub@linux.microsoft.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2543336vqr; Tue, 30 May 2023 17:10:48 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ41r1mbWcMV8nuAmVMKjSc3hLUXP06uDo5jzc68QOPdlxJK1fY1CFqvZjTwlf4Vq9Ndy4hu X-Received: by 2002:a05:6a21:900c:b0:105:23cf:747d with SMTP id tq12-20020a056a21900c00b0010523cf747dmr4041851pzb.5.1685491848654; Tue, 30 May 2023 17:10:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685491848; cv=none; d=google.com; s=arc-20160816; b=KsvTPfVKNjXHTdw1PzEv/Pep2BAGQ6lxCB3YUU6Z89ABbgoev6chjoxPvqU9g2QlWu zhOONH9/F23Mbg8EgYe8hcPVnspDwXtaMJd5QKR6Ji7GO3CF8fELZawPk69WorhyZDfp 1sn9g1lpIAHjmZzCM1Y/1o2DR4Ou17mpP3rKwNInhOXTLyCn7G14P491knBQnwCSAjns p/HmEJtFntL/J/IqK6fE+0mv7Qb8AjsXLetOvdkKtHmLi58l9vG2U9o1WWhLHXRiwEoU ryz8O004ulOyZ2ggsh0yJ9L8ps0Rdb0L3xgiL86Z8vOj59QrgRu6NNndbmnQLD44XfHa ZiMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-filter; bh=Z9owk60mLsQ9CmOnrrn5zp1mIr1kGtuAxKwMw6iuEA8=; b=sPWdiLzW3tQkzOATw9iYIkMdePRit2HHmAUEM3dLs3B181PVRcVYlvuQpdN03Hljho vj0+6BdcyHEy+Omf/aBHXdUWaOjsfEpyLZk4/387b3VGfrumrnLMRWaepA3KPLmKU94h 2Je0CRax1iDP8EGCqnQlSYXVdtr7HFaHSWjbruyHnkR8wEdN17bRs3+ygeSALZif9/jv 2IUPEHtox1q+x/dhuqrFox9UAKZNUO96JpZfbku1WPF3iI4Pg5z2i5p7A9ZUB8/2I16K Nj2WN+FMplc/KuekG2DSkF/ZY74GR4jZ5FHsIpgpilgA/4bNtpNtEWnX1yuODqelDxqD GW2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=bmV7NDmU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h190-20020a6383c7000000b005348a615896si4906252pge.113.2023.05.30.17.10.32; Tue, 30 May 2023 17:10:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=bmV7NDmU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233971AbjE3XxU (ORCPT <rfc822;callmefire3@gmail.com> + 99 others); Tue, 30 May 2023 19:53:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231960AbjE3XxP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 19:53:15 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5BF86AA; Tue, 30 May 2023 16:53:12 -0700 (PDT) Received: from W11-BEAU-MD.localdomain (unknown [76.135.27.212]) by linux.microsoft.com (Postfix) with ESMTPSA id 931B920FC46B; Tue, 30 May 2023 16:53:11 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 931B920FC46B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1685490791; bh=Z9owk60mLsQ9CmOnrrn5zp1mIr1kGtuAxKwMw6iuEA8=; h=From:To:Cc:Subject:Date:From; b=bmV7NDmUKut9lVN6Gvy8cX/SOgoVrBGj33TsV9lFkCIZuKLAmFtwIhhaIuGxP/E6T 80lX/RosXgdoXKkJfrikQ1vp6iGSAqt5s/Tmtot07RlOwgTJPi4vxOm6YvSnCh3Rzn ZkzBpfeARZOkmtoZoBBmTMPVRdM9R/tnion8VfjU= 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 0/5] tracing/user_events: Add auto-del flag for events Date: Tue, 30 May 2023 16:52:59 -0700 Message-Id: <20230530235304.2726-1-beaub@linux.microsoft.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767366300503323153?= X-GMAIL-MSGID: =?utf-8?q?1767366300503323153?= |
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
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 >
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 > >