From patchwork Sat Feb 1 08:31:27 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nir Lichtman X-Patchwork-Id: 13956124 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 4591FC0218A for ; Sat, 1 Feb 2025 08:31:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56C766B007B; Sat, 1 Feb 2025 03:31:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 51C1B6B0082; Sat, 1 Feb 2025 03:31:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E4766B0083; Sat, 1 Feb 2025 03:31:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1FA856B007B for ; Sat, 1 Feb 2025 03:31:30 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 967DCC15F8 for ; Sat, 1 Feb 2025 08:31:29 +0000 (UTC) X-FDA: 83070706698.23.93B49B8 Received: from lichtman.org (lichtman.org [149.28.33.109]) by imf12.hostedemail.com (Postfix) with ESMTP id 24FF44000A for ; Sat, 1 Feb 2025 08:31:28 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=lichtman.org header.s=mail header.b=UzG5Bsyt; spf=pass (imf12.hostedemail.com: domain of nir@lichtman.org designates 149.28.33.109 as permitted sender) smtp.mailfrom=nir@lichtman.org; dmarc=pass (policy=none) header.from=lichtman.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738398688; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=nbo7z9Xh0Q7NSRgeTYxXiKEKD1NLhu2dGKUmh5HW8jQ=; b=h57YgC7NVYuzZg+WzVxiXTOyIqA2P2uhiJz4VRaZAfsYdZ7IphdcQ4Kplx7dDpll3jUayq Zx+2XfMDWMdCThbpzliVcoB2XS4okQtMoTXp8XrUUpXyetMWR+xDPGcwJ0pyViB534MFlk kvszidyQ4rLCEOZIpLmC1dqBxdjNxhQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=lichtman.org header.s=mail header.b=UzG5Bsyt; spf=pass (imf12.hostedemail.com: domain of nir@lichtman.org designates 149.28.33.109 as permitted sender) smtp.mailfrom=nir@lichtman.org; dmarc=pass (policy=none) header.from=lichtman.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738398688; a=rsa-sha256; cv=none; b=QfAE+lfRDYRU5wBKuzPuA8/uJuAPNgGKHXz79j7dGMlx1eKoTxWkd+LVGVQuK4mWho8Z3i UWOqJIVH7DW1UbJ0fivs5Y04gQQUisGOubcsdbb4n+AAXakOvhoMu8N1cPcKRuMRx6pS33 9txvmapsw+FEuLFgeD/Bg4/aR0XpYOs= Received: by lichtman.org (Postfix, from userid 1000) id 5D0731771FC; Sat, 1 Feb 2025 08:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lichtman.org; s=mail; t=1738398687; bh=EtORstMEP5vEDoFhnNOmFLeQbb1NNqyYFa8DuPRNgYw=; h=Date:From:To:Subject:From; b=UzG5BsytUmXG7G/2Pngkuyfo4JKYtwlyDIYVHxvrx/hLhecdW0zJc5b0i+vLGjoyz pOSuR2IR2bLw8i80onDVs0Epg8ohxX+U06hLsYzhDMCF33EF8TRwRnmjZFHOdckAK4 0iA7u+VSzkKaCSvwy/wdUy4wj45LGDZxENUiJ1QyBpesO+w4sdWFcYtZvDSySiTohu vYTytAfFHUAYu7MXF+TXA5i3JJjBxHm9JvQOGRFRzHWPeBktbqjcL83dUibAsc/PMh jCWq2slRAl90b0Lb1dmbkqmNX1pJcbEk2Aejun1WHjxOyof+m958kzAcBYE3dLo3PS +xhAoNqEm9Ncw== Date: Sat, 1 Feb 2025 08:31:27 +0000 From: Nir Lichtman To: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, kees@kernel.org, ebiederm@xmission.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] exec: remove redundant save asides of old pid/vpid Message-ID: <20250201083127.GA1185473@lichtman.org> MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 24FF44000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: s3zwhssdxaubi5kzba1e3rw7s4n9kppp X-HE-Tag: 1738398688-776481 X-HE-Meta: U2FsdGVkX1/BmIMGglMsgU2liEG+naRlFaWFSnEipkLH7CX2KaIjXXfHt0ipW1o7GZ5FOS72KW/y3n9oyBL89g0AsnJCIdC5G52JQF/VVbKl2iUhONdq83BHmYMTV8Ysf6U5nOh9qbjrkCsvg61/Kfyft2Iul6A2GwyNp3vbuqfKXsP6QjmeCUslARevjK6IH77EWXgQfektxI7QLYjVB3LeKKnbFaJwLEKTmgqUZqnpIZapbC0wF4khNNzJrUSMhSKR05oM1GuC3CDXeeLMSmYe9IaF8Ix+zm4W2nhrcyGTxb/E6sQXGkLxMhy+ph5XYd6LO2B6GzxvXwze2DR00Z7L5Bt3BPr2/XAQ7e6hyEFF/YWCioFZM8F2r5lBzHVx6br90E8sa9AXHaIT5KzvG0KDbwNayhvTC8zbhis7Y/LCxLQemiesDAaL/TdmM6zuyKJGT41Jl+Dn9aw+oAFhX2CZZ8m4kN+9FmxNRORHBYeUinrQSne1rqVpwIFnQ5mMiyI1QOtdmjPiXgmeBG0uOYEDGl4xgUSEftXjuIwiHzOH/xgFIeM2rgJX+RkX0AiDv9cEV2s8rABYrG2WNv6aHsVPFwbJmgqJUes8sPXY+LELV3avcnDzhQNRRG96aHStjQer6ZHVUyinZY1TaGRth2SjJhpxC6shm7Sm2HrTC1Y7/LSZvDdcIEIwD2t1QZJXpyH0VfEVbJAxolkJ1uSBp85Z8SJYU3QPUk+Rp3EvQ0Rw3yzsxcSPS/RTYjlStwhpy9Wd+ZuxDMJPG95k0r5c4ZAqc7u7eYez2qGxMgq95NDhnFKxyrnF9sszm1UVibQjyHlmeB4JhDgmSCr7ePQU0JKoUsgo7sjptJP4hl6o21pPsOEWltfgWSfz4UPE6hV5qr39g4YQ7ZYYjNoz3sFMNsxucRYB0pl1qhrPisEjzc0wCDpKWrDKAAzXuTPWD+24Jd2vSNJmYlXNHgHeDtF vRr/KhGR M6zjyA7uzlTbhdVs7J314alykFirm9c97/0WO3nUBiAfAkAPn5NUpYRHQiJE6XPXYTdqlLxEhHLNej/ie1OD1ZScBo9XE2qFBXXYuvqHZzGRaFFs9ZWkfpDAbD6v44q4FaOwRkyxwXLId00TLdRwyvtojblKWFLyKAExhL7KtaZaB/4Qaqyvj944v2EXMxpawR1aImXtx4e7L/j6GOizoNvuwbob+JKt2FYzdWrz6OfiHtWs8tLupI1b+35hl5fMV3TtoW9sLT0b32prtrM6c7QSV0w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Problem: Old pid and vpid are redundantly saved aside before starting to parse the binary, with the comment claiming that it is required since load_binary changes it, though from inspection in the source, load_binary does not change the pid and this wouldn't make sense since execve does not create any new process, quote from man page of execve: "there is no new process; many attributes of the calling process remain unchanged (in particular, its PID)." Solution: Remove the saving aside of both and later on use them directly from the current object, instead of via the saved aside objects. Signed-off-by: Nir Lichtman --- Side-note: Tested this solution with a defconfig x86_64 and an initramfs with Busybox and confirmed to work fine. fs/exec.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 506cd411f4ac..6bb0a7b15f7e 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1789,15 +1789,8 @@ static int search_binary_handler(struct linux_binprm *bprm) /* binfmt handlers will call back into begin_new_exec() on success. */ static int exec_binprm(struct linux_binprm *bprm) { - pid_t old_pid, old_vpid; int ret, depth; - /* Need to fetch pid before load_binary changes it */ - old_pid = current->pid; - rcu_read_lock(); - old_vpid = task_pid_nr_ns(current, task_active_pid_ns(current->parent)); - rcu_read_unlock(); - /* This allows 4 levels of binfmt rewrites before failing hard. */ for (depth = 0;; depth++) { struct file *exec; @@ -1826,8 +1819,9 @@ static int exec_binprm(struct linux_binprm *bprm) } audit_bprm(bprm); - trace_sched_process_exec(current, old_pid, bprm); - ptrace_event(PTRACE_EVENT_EXEC, old_vpid); + trace_sched_process_exec(current, current->pid, bprm); + ptrace_event(PTRACE_EVENT_EXEC, + task_pid_nr_ns(current, task_active_pid_ns(current->parent))); proc_exec_connector(current); return 0; }