Received: by 2002:a05:7412:cfc7:b0:fc:a2b0:25d7 with SMTP id by7csp2424639rdb; Wed, 21 Feb 2024 07:19:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXN2fxw3Av5PaJwroek+whCF7lDS1Rp+IjuFlAbSHGPKq6DPuXz3z3WfMLpmgahe5FGqBUNaZhDqbGoupXfQUIdc0qzs1f/YJRDrcdKhw== X-Google-Smtp-Source: AGHT+IEa598sS9IJHGVymeZjFFFTUOHp6JfXWcdF5Xs8ANBmZIpCe/4n3MCuBNyr5Fnvt5L+arMd X-Received: by 2002:a17:902:ceca:b0:1dc:1557:133b with SMTP id d10-20020a170902ceca00b001dc1557133bmr7426520plg.11.1708528763598; Wed, 21 Feb 2024 07:19:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708528763; cv=pass; d=google.com; s=arc-20160816; b=LFEMTM3bzJSoNu68lVF4m3bLLOtwtzVaXYriXp7hyQ1FybkD8ylVlS4FDrMqH4Sap7 ky57v+T3litG6XbFEb+j0ccJf2rba/Jx5Y5w+NlB8xjEzh5dlJhwfzHrX72Vf8QoICJM /YXMkGzEgNRvZNNBJv4SEX9ATkyGXmqWvhF6Y6nLbH4DCnsrsHJdaTXX7wqE/0d3iU9W KXjtYdIcxAXk4iXZYpRxJcdlN/80gCjPz3NJLuCcQr9Unw6q3zfRjaWeGenOYgL92LF1 858agxuCxHTXhhBUc8nVHMbCpA6tLFS5APqH8wsbmOxhctW/H6fS2DcK0NmmKEVx8UB5 AJTg== 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:references:in-reply-to:message-id :subject:cc:to:from:date; bh=peyGwK2+r0Lav3qWqkClDVFLpMoaU5deioXa+hUJShs=; fh=UgJ1M/WLDuBX5Hd7iWpdBibTSPJm5+ZRhFuzMIW+uy0=; b=M4jDC1hXQdBT9fV+mGsV0iLDgtdDrUQ0b5uesg3HNqHIU185TyZ4Da0kWvlJK5PT8J R3yjHevAcmjKpmhGBXXLPYaY6ppdSHKysT0PATQeXrLSBw0XxjDw+JUCZPAKc9+olggl uR2BXmhddp8Wbde3bBBR6hfsHgMX36VDB0m7mAowaiWImDaAzZ+GWBv1IC9+zIMROrv5 G1duWLeRtRjMiVbijhu3FSvjdn/OFeFwibYzOrEmFErSeNfcg6FIRtVCB823VewRtZIK 6nJ+SnSFsB7l9aOmwtKgAnP9aZ1Cg933QmtA9ZjJQfQiqlOeF5NZLJtHkQmBP1rfFFEI Q0dA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-74985-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-74985-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id e38-20020a635026000000b005dc90546100si8134557pgb.295.2024.02.21.07.19.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 07:19:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-74985-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-74985-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-74985-linux.lists.archive=gmail.com@vger.kernel.org" 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 4F0CA286A81 for ; Wed, 21 Feb 2024 15:19:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D678480613; Wed, 21 Feb 2024 15:19:18 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 586E280050; Wed, 21 Feb 2024 15:19:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708528758; cv=none; b=It16V+tRLy0efnQZHoaPpv7YyUrb30YELd//X1/C9zFXV3g1qul8r6y9NZ6Y8XnzOUFsiTpjiMk0F4hh8ZPCN1vNpeTNhcEVzCHk3ZtVzL0LPZG6PVRO6CVillRdJ8X4OpDYYak/teHVPEdMsHq6blP87wo5VOs+BKUuc/6Fr3Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708528758; c=relaxed/simple; bh=iKOHI6CLp4g2NCjQ6yWgSXnY2MzK0cTPEJKpWfebVYI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gB9x0vedJayTTdtSqBbJJ0tHkNtTmaLIFkG0vtO6y+bADDt2bO0r9IIW2kXm98bLLZ7I/6TkkAPvf9LydjvB8QOO18IDNeqrhyjr9ErmY760QZD3zxSup9meX/9/BYr8O3cICMtS6ILJRDLQWzEsPJvp801CVxkArRxMfAG4Hos= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04260C433A6; Wed, 21 Feb 2024 15:19:16 +0000 (UTC) Date: Wed, 21 Feb 2024 10:21:04 -0500 From: Steven Rostedt To: Beau Belgrave Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com Subject: Re: [PATCH v3 2/4] tracing/user_events: Introduce multi-format events Message-ID: <20240221102104.6ab80e5a@gandalf.local.home> In-Reply-To: <20240214175046.240-3-beaub@linux.microsoft.com> References: <20240214175046.240-1-beaub@linux.microsoft.com> <20240214175046.240-3-beaub@linux.microsoft.com> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 14 Feb 2024 17:50:44 +0000 Beau Belgrave wrote: > 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 "of the event in the future." Does it have to be in the future? Is there use case where an application might legitimately want the same event name with different formats? -- Steve > 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. >