From patchwork Tue Jan 23 22:08:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Beau Belgrave X-Patchwork-Id: 19351 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp638643dyi; Tue, 23 Jan 2024 14:24:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IGi4Ua5PN6JejtMteJ5AHEadtBKeQcQp2STD7u8ygChZGFmc5+xpOHovgnnQW+Gaj/rLZL2 X-Received: by 2002:a05:6358:52d1:b0:175:75a2:62a2 with SMTP id z17-20020a05635852d100b0017575a262a2mr2284590rwz.46.1706048695255; Tue, 23 Jan 2024 14:24:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706048695; cv=pass; d=google.com; s=arc-20160816; b=J7y2j+PdD0L2PtLmz87/ZGFZo8mmN/Pq1poiITFIUyFAlEcOpVbRWTQvtasZdEw0Qw BzZ2TZluukV391b1r401RhBERnelN5cIO7ZmImyIdBz9q4/130doToET1DV9cBRCA77d c55DJ/59KbepFCWcveIiahocAziukNJjo2V54yY8y2+ukiLOhTf0tSKbNUu6//Fm7J+V I6YCEtKnwxcZbffXHF9G7sCV6ubR8YrgNMY8B1hbHU+MW9+8W4n5E60xQf6hME2/V7Mw 5Hh+nfTJjyDb9bgnfYhTj4lwdN7b7JlEg3ptyg7eCwzqWo8p3njgdHAsBFUU4xNo1BGm jEkg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature:dkim-filter; bh=bEfWYDXjszLhtUJ60Cu9ub34bsEWpGoaORHmdozbgOI=; fh=IUXlFtcfnvZk04FS3qaK0sXInhvXZlQ3mi5m9ci/vMg=; b=UICHdP91XTW6IFASL8jZopfn7y4VbasK1pWU4u/OS8AVR6e147A/+reXZL80Wq8j94 FTyoPAT7eV9Fbd8CIzw/GkJRIX1hwNJN/8djrr2u8u+8bcTR+vpRvDS/1i55pYGPd56r N8//UdTU5/d4G98GgTEu7n43nlcN7NWNbhjyq0l3h8e9jW9h9Azu6utN9f9oY5ZSB8yR bSnzPoRG3ykzuvIoqf3aNJ4S4+vc3ysW8MAYrswsblscoxlvu0yXV8x6pj3piV3XrpiG 6TjsnR2hl1K/mJEwuxeDqRCLocPZK9Q1efIyM2k/tQNlTuKbrE3NADF+tvsSAFhCJ2FP Qv0Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=IfVx9G7I; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-36114-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36114-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id q18-20020a656852000000b005d3a25c02f3si1548692pgt.769.2024.01.23.14.24.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 14:24:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-36114-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=IfVx9G7I; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-36114-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36114-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 4CD3CB2767F for ; Tue, 23 Jan 2024 22:09:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0852050256; Tue, 23 Jan 2024 22:08:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="IfVx9G7I" Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C6E224E1D0; Tue, 23 Jan 2024 22:08:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706047734; cv=none; b=Fi1ZAWRPB+zmv2AtTMfiSHnEBYlHmC1dtVNxwDPy+d+C+RLMqSBXr5KsmyzO0Ze4EWjThTSJpKW4YnQoVeoWlSixab2mJ5HnTZRL3xWB6NX8arhe2z1eRPdefLhCHT4tE7x6VNAM5fHvUlxW5bLJE2bquaVNkAE4KC06mnVtvMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706047734; c=relaxed/simple; bh=ymZLlbzgF+6RAj1E0FlGUaNHOf2JMEO6loXEClZrnFo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=ADqLoa9/cLf7Zctl3eJyynjRhBK4M/rqMtj4foXaRJSYrduF93E/Qb3sz1ZdZlTuLS90mc6dS76XRl5cWPaQ8VsLmfvucPSp+HEUFbtK/tT7FsIalyQcpN8rFOrGmI+9/beUuIcw460k388aSL+/mWRT9dKctLjPqjekHOcc+iw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=IfVx9G7I; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: from localhost.localdomain (unknown [4.155.48.122]) by linux.microsoft.com (Postfix) with ESMTPSA id 544DA20E34C8; Tue, 23 Jan 2024 14:08:52 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 544DA20E34C8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1706047732; bh=bEfWYDXjszLhtUJ60Cu9ub34bsEWpGoaORHmdozbgOI=; h=From:To:Cc:Subject:Date:From; b=IfVx9G7IqRu1Ivn1sFKQ7IXPcAWmEaSDo9LJhk7h52yHcPUp8CAOFdqeZWZ95aMWR TQ0fNWrjOozMia11x9lOyVLhTh8di4/nyU/5UPbV2JcVxdhRAa+mxsMKGllu5L85oU iCQQnPV76Ai+av9aEoNQRNW4bS7gG5VLobnKg9i4= From: Beau Belgrave To: rostedt@goodmis.org, mhiramat@kernel.org Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com Subject: [PATCH 0/4] tracing/user_events: Introduce multi-format events Date: Tue, 23 Jan 2024 22:08:40 +0000 Message-Id: <20240123220844.928-1-beaub@linux.microsoft.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788920815126095880 X-GMAIL-MSGID: 1788921716325686868 Currently user_events supports 1 event with the same name and must have the exact same format when referenced by multiple programs. This opens an opportunity for malicous or poorly thought through programs to create events that others use with different formats. Another scenario is user programs wishing to use the same event name but add more fields later when the software updates. Various versions of a program may be running side-by-side, which is prevented by the current single format requirement. Add a new register flag (USER_EVENT_REG_MULTI_FORMAT) which indicates the user program wishes to use the same user_event name, but may have several different formats of the event in the future. When this flag is used, create the underlying tracepoint backing the user_event with a unique name per-version of the format. It's important that existing ABI users do not get this logic automatically, even if one of the multi format events matches the format. This ensures existing programs that create events and assume the tracepoint name will match exactly continue to work as expected. Add logic to only check multi-format events with other multi-format events and single-format events to only check single-format events during find. Add a register_name (reg_name) to the user_event struct which allows for split naming of events. We now have the name that was used to register within user_events as well as the unique name for the tracepoint. Upon registering events ensure matches based on first the reg_name, followed by the fields and format of the event. This allows for multiple events with the same registered name to have different formats. The underlying tracepoint will have a unique name in the format of {reg_name}:[unique_id]. The unique_id is the time, in nanoseconds, of the event creation converted to hex. Since this is done under the register mutex, it is extremely unlikely for these IDs to ever match. It's also very unlikely a malicious program could consistently guess what the name would be and attempt to squat on it via the single format ABI. For example, if both "test u32 value" and "test u64 value" are used with the USER_EVENT_REG_MULTI_FORMAT the system would have 2 unique tracepoints. The dynamic_events file would then show the following: u:test u64 count u:test u32 count The actual tracepoint names look like this: test:[d5874fdac44] test:[d5914662cd4] Deleting events via "!u:test u64 count" would only delete the first tracepoint that matched that format. When the delete ABI is used all events with the same name will be attempted to be deleted. If per-version deletion is required, user programs should either not use persistent events or delete them via dynamic_events. Beau Belgrave (4): tracing/user_events: Prepare find/delete for same name events tracing/user_events: Introduce multi-format events selftests/user_events: Test multi-format events tracing/user_events: Document multi-format flag Documentation/trace/user_events.rst | 23 +- include/uapi/linux/user_events.h | 6 +- kernel/trace/trace_events_user.c | 224 +++++++++++++----- .../testing/selftests/user_events/abi_test.c | 134 +++++++++++ 4 files changed, 325 insertions(+), 62 deletions(-) base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a