From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64D80C67861 for ; Tue, 9 Apr 2024 14:46:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB9146B008A; Tue, 9 Apr 2024 10:46:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D68D96B008C; Tue, 9 Apr 2024 10:46:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C56BD6B0092; Tue, 9 Apr 2024 10:46:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A7D736B008A for ; Tue, 9 Apr 2024 10:46:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D689C1C04C7 for ; Tue, 9 Apr 2024 14:46:29 +0000 (UTC) X-FDA: 81990269298.19.B2E9A25 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf15.hostedemail.com (Postfix) with ESMTP id 115CBA0022 for ; Tue, 9 Apr 2024 14:46:27 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZGsALeMK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712673988; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JGKKqyMnDxDe7Z88TFPiX7ZbsHcnXFBE7VSZEtRsFEI=; b=6mtmzPdk/iL/jRlI/gYVUZ8x6GY97xI/eghpReqXatDM1ZgSP4zWe0G4YzlbeOpViGtiYJ QKUVHg36YYF9yyi7BZ6pP5ldwAOsPnWdRc6F1nXiGugf2+yfk2ZBKT5IQV7W8ee7NAGgKP M1BryFP+UfV3RmcWila5MZzRjF4yjS0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZGsALeMK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712673988; a=rsa-sha256; cv=none; b=S+xUJl9izmwgiR5aH01maJ26VsMLZuJ6rx2jyGw5NvpJw3gduZa/ZT08+TdJEZKtYQFyTH ULzqL+WCJ4W6yhiuSaRFD4Ir5JmmLyi8WCKnPr6/bR67pAubJ1WRBMMiVl/23XOgJSUGEs ecIxnGifF5j+Yl3GmWoROETV4nnixkQ= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4daaa559464so1590434e0c.2 for ; Tue, 09 Apr 2024 07:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712673987; x=1713278787; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JGKKqyMnDxDe7Z88TFPiX7ZbsHcnXFBE7VSZEtRsFEI=; b=ZGsALeMK2n6ljZVixFlyBod8Xzy1AjmC/gew3K02Epy5fQ7ZCbz/EHJPoY+FR7Ing9 ltlM8f6TRaNDNDk+MKl0Q/dGV0mo5acFy1CaD67Kp71wLt6vr0J8/xzHy1gEaztYnrSn oQ060JAkLy3gh1f63NYmCYlHeoSyozhNEOKGyO2qsEkc1RYhlEqOM1nkv/QKzyPgT4RZ ZOJuPtUT0ETgUSBjoDq0eko/kxvkBZPjyXTNQxf9eE1mu+Ow5cwEpbE79qg4NC4jSd7k ObyGMvjMZxfbuSbS5vvh96CjgDMjCrrRxilbE9Jfs5IIVKQbbQ2pUsWoyuqpKYGxFSJR rZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712673987; x=1713278787; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JGKKqyMnDxDe7Z88TFPiX7ZbsHcnXFBE7VSZEtRsFEI=; b=UfBshQOeFs6Tk5Xv7TdTuDfFRg+Gjhey8r1KZQqeYfrpzgQD01OsH0JolNAFoTx4+j ihwwuUhmB/823EQLpvGdpgqkC3Wjz5iaqiBWr2zdHfeulLGL7Nvdo/ae68By0A+BE7/c vMIR/fqxWuMTRvIkkJJ39JjPAukmHwYr7RdXAXJRf2ishJ1H6CBpHHM5vAJ2sJV9t7yX J7C2hfDfBtFDa1/qJO2TpkyPLL5FojnCHBt3m3T0/T96h3PxIj3ICdDU1TnyEu0k+nm0 Eio4JAM3J3xGvQqzqmbJMAegWTjUsJ+p+aYcUmpkp8GAXmbhCZG6JkQMXhlfi7Pucjep kUqg== X-Forwarded-Encrypted: i=1; AJvYcCWxO3UGOdYgt7sGbpCUbJy+iDiA6OYrBRq5/2L0T/HcA7nrBVjjfJM0gFlXVKVo0ZZRxllYKynnKUS0LREzoCXyNqM= X-Gm-Message-State: AOJu0YxxUv7NNuONYwmdV27dIGOAYGOZNJFjFBVCZMZAlm8dju6rmftf +97aky/6dU3YM7lGes83USwimE04LZZK1a/UldT7YsvtQWp69ocIPASMMtkzrtQ9LcP1l/j4hHy E0tvjcJ16PLdav/O15+NnOivkxBq+4+AZmL4v X-Google-Smtp-Source: AGHT+IG5ZyVYbzpi7MrZFfeuZePmTlO9Cj6SrZUQgNIArSjr/qGXL8vsPlsLH60WkxdNp2m4CZry4zLpVpcPiYwzY5k= X-Received: by 2002:a05:6122:48a:b0:4d8:74cb:e3c2 with SMTP id o10-20020a056122048a00b004d874cbe3c2mr33094vkn.9.1712673986727; Tue, 09 Apr 2024 07:46:26 -0700 (PDT) MIME-Version: 1.0 References: <20240408090205.3714934-1-elver@google.com> <20240409103327.7a9012fa@gandalf.local.home> In-Reply-To: <20240409103327.7a9012fa@gandalf.local.home> From: Marco Elver Date: Tue, 9 Apr 2024 16:45:47 +0200 Message-ID: Subject: Re: [PATCH] tracing: Add new_exec tracepoint To: Steven Rostedt Cc: Eric Biederman , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , Masami Hiramatsu , Mathieu Desnoyers , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 115CBA0022 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 4x9mtd4hrd4iisurdizd51imswnknytd X-HE-Tag: 1712673987-461409 X-HE-Meta: U2FsdGVkX18YKkTCd3bkOcFgiFrTLST4UeoOYWYyDzdW4wYWcCMZCA6E3ZscEC4cDvxCDn/6Yn+msZkHUgKkgqWchwTYS1ivLQhPhoHnPMSXbXTh9OG40BIMMUjwmo+BEBK7dGtdjyG9e8kkWFQsJyEbdYP73ktE7rbBpEfc1evOjvoRF4aVS/91Bx7jEFW7uKGqOdWG6/aQY+GX10MoJ0x7vGofJzBNNJZWN2HGFbWk1hKlSG0qh5SkG3QPEBR+9Avfrb3z13MTfNEeabZuY/CQ6bo1hKoCVOGG0OZ+zwg14tN/Ad2exTVyyG1/fyItAlrdWhSEz4IQOdqU0E27uU7t+gK6kW3l0Nlg91OXyl8O1Q/qQCBIQfLiuTTySyXzcCG0zkoud/Qi5qkfNdBn5hWDklGKueKe9FUI7VVIArcJulfaT2KyyCj8PKDijYVR+7AWa+yVhmwpZgd+cjw0NEKv4sXBiP1aDgPkqzpm9LALJnyiQftpp81QUOva8Fwxk1lFWqQRNOD6FRvM4T4lTEFQvw/vDZh2jUtrGR6XBMIHAzzh7oajz9uPvZ0REXVGurj9xiIWlBKz+QA/nGgVNphVB4PZPLee9yfzjVO5sY52upNbYQSX4+//lhQ285VmaN0R2rc00jeGVxTaezG18MpbuemFPyaU7RzsFHhkCTNrzb1bf8lVtKMSG4Q5Q9eeQLLVpihbwdpYdDCTe2xLx/pers2m0v2qiNt9Y2GuJ2WhaYPVKZ1Nd+WLQ/yVh/otzaOcLNjb5d1KQ+k96tXikhB3EwkP8AU0yJcYPAHl57c4gW79bQThe6YVh+pumISLUpHP0p301AUK7b+fAqgIsaDrU19m8S46y7I0x5RuZ13ILpnNQN4yHD+gWz4CipIPJxzgARqzKoCnq+w7nGxl9KtAsKDhg8gfJow4OBW6vHPXqn6NIIQEO1m/FjsUvitampXToWZ9ck0SO+sx62K uSNeS9np Q9W0uHRV1w/12hpkBZxW6Yw3aCMxa6Kb0EBwCOLaSHU05uHrIA3GjFIBjh2xfOmlVq8uSqe9lMwsyfdFHaYRHHQXM9yIERpRCqmyEkuaN9ZZTj6+IH7olM15qQPjUhqChrd6glQ+ZH+SgV3CDGh6GfXKgkH2RzhgprjViKEP4yoLs/ItSKs5Q0J+sErhIQJMpLiNYqKkDS3dAn052CewEzEwKjv6GBvy1WKqBfCEGpem54zjG4tE4DPB8aq0ookKxf7jq4WJ68MElrTXxA1iO5aJBnc2foJ7tlrJ7PM5Q4F9V/+wogl5zVDCsleUbeFTrkCbe/KasUNC+t33W9xXV8j7F12++iWyGiqwXvi+usogDzIk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001512, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 9 Apr 2024 at 16:31, Steven Rostedt wrote: > > On Mon, 8 Apr 2024 11:01:54 +0200 > Marco Elver wrote: > > > Add "new_exec" tracepoint, which is run right after the point of no > > return but before the current task assumes its new exec identity. > > > > Unlike the tracepoint "sched_process_exec", the "new_exec" tracepoint > > runs before flushing the old exec, i.e. while the task still has the > > original state (such as original MM), but when the new exec either > > succeeds or crashes (but never returns to the original exec). > > > > Being able to trace this event can be helpful in a number of use cases: > > > > * allowing tracing eBPF programs access to the original MM on exec, > > before current->mm is replaced; > > * counting exec in the original task (via perf event); > > * profiling flush time ("new_exec" to "sched_process_exec"). > > > > Example of tracing output ("new_exec" and "sched_process_exec"): > > How common is this? And can't you just do the same with adding a kprobe? Our main use case would be to use this in BPF programs to become exec-aware, where using the sched_process_exec hook is too late. This is particularly important where the BPF program must stop inspecting the user space's VM when the task does exec to become a new process. kprobe (or BPF's fentry) is brittle here, because begin_new_exec()'s permission check can still return an error which returns to the original task without crashing. Only at the point of no return are we guaranteed that the exec either succeeds, or the task is terminated on failure. I don't know if "common" is the right question here, because it's a chicken-egg problem: no tracepoint, we give up; we have the tracepoint, it unlocks a range of new use cases (that require robust solution to make BPF programs exec-aware, and a tracepoint is the only option IMHO). Thanks, -- Marco