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 187C7C4332F for ; Tue, 7 Nov 2023 23:08:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0C24280004; Tue, 7 Nov 2023 18:08:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BABD280003; Tue, 7 Nov 2023 18:08:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A9B1280004; Tue, 7 Nov 2023 18:08:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7E944280003 for ; Tue, 7 Nov 2023 18:08:50 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 421BA80BDA for ; Tue, 7 Nov 2023 23:08:50 +0000 (UTC) X-FDA: 81432700020.07.B1D9D69 Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 7E11B4000F for ; Tue, 7 Nov 2023 23:08:48 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CPnPtSco; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.50 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699398528; 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=Xdszqg8GuNrbv2D5/m8sAm5VRvjmMoJFaLE7yW2b4M0=; b=AhwmxwEuDvf1kd/CWcP/7cot+zIkCF4+FVP4vdqx62OctjMy1nsq/P9ieO7PnBbYg0I338 /DLGd0gJ3ZdWbjBCASicbHJXcyyCC53BgtYsM9tRea6N2giYulWKMeNzEOjTEx1nHBYI+1 EcOs2M8q6DU6JWx340XidR5QhJ5FITY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CPnPtSco; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.50 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699398528; a=rsa-sha256; cv=none; b=tIPcrU7uwQPG3L60noNQexA/nhrd2MoL8rlYRXeZwRLLr3pEuGt8W5R23mtDZ9/FBW5wel ofoxQZ0ZCRYnKjXe+sA1DTV/kYAoI2wXhXb85AdJqGIDwx2m86DPooBGndxUEheW5J56X5 9Ut4/HhRFwN7YVfTGtjkO+ra0RVw/4A= Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-581f78a0206so3320514eaf.2 for ; Tue, 07 Nov 2023 15:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699398527; x=1700003327; darn=kvack.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Xdszqg8GuNrbv2D5/m8sAm5VRvjmMoJFaLE7yW2b4M0=; b=CPnPtScoQUkTsKaVf065N8EZ6+Tj8RnJPx9+UY6UojVuQ5ei1c7xjGJ7mPSGSTD5Wg MoS4G2uym0UwL4AjheTgChwEHvvBGhIx0OQY6wOkXTwNWt0n5ci/maK0Cxe8YkZvCZZW KtHjfLDV4zjnt4VsQEh3dfs++AapduoEmnEsaw+sJ5hBLUzrrypG71lsLrWereVtGXU6 AanWgpnpb5Jt/XKt12zhuJRVOMZg8k2iVDYMGtsd0gWklbvkehphbAxofU3I+BLK+RH0 mUr+pkVKqiNYLQMk3uki3aPUGJZ8KHNle1IZZJkp9CxswvhmX8Oq6aFBdRwZfBikD9fr H17A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699398527; x=1700003327; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xdszqg8GuNrbv2D5/m8sAm5VRvjmMoJFaLE7yW2b4M0=; b=dAfZhkJgKbCwHnlsY+rFBbkbZHYxUQDFhVCRaVhONpAzblZVrIs7RSOgXQG9kPanfQ NQNOXbM5XixF3tnCOyjGyQwP0U3zU0MOGiawJ//fqYke9YpcmajlWMrn8b4P3aWQgiCd EnRBps4KxUAnfAuYSDbzD1gNNzDb9vX4MOyI2/2LLr9PwkkmjG5YoLnnnq1WDWucwvj9 0lduhRMnnV2mKZkgvCVYVbsX3BK5mIwdWZKg41bnFH2Hp7hbSouFIfsMQcz+ub5dGmpG HM3VQEkGyVRnxQwXkI6AuIG1N+dFhbXFGbjIMvze0nNHqXoePajxAmOL3D7hGHoIlbvz V0WA== X-Gm-Message-State: AOJu0YyaYGcikNsSzvpEstN3at8Vh6xkWJ5gJ8/KK51JNelLP8R3ZZxx NIPvdsIdXZFdc5aC7mvovMpOP6Df1MlNnvzu4lI= X-Google-Smtp-Source: AGHT+IHsp0JJKejPgiujjZaFuuv8e9Qy38owaFGrdM72IJx+emIxMLP+QGs0DogjaSs1V4wz96473ZBZbE9tYUFVT8M= X-Received: by 2002:a4a:3152:0:b0:587:9928:a0f1 with SMTP id v18-20020a4a3152000000b005879928a0f1mr264895oog.0.1699398527593; Tue, 07 Nov 2023 15:08:47 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a8a:158f:0:b0:4f0:1250:dd51 with HTTP; Tue, 7 Nov 2023 15:08:47 -0800 (PST) In-Reply-To: <202311071445.53E5D72C@keescook> References: <5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org> <202311071228.27D22C00@keescook> <20231107205151.qkwlw7aarjvkyrqs@f> <202311071445.53E5D72C@keescook> From: Mateusz Guzik Date: Wed, 8 Nov 2023 00:08:47 +0100 Message-ID: Subject: Re: [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm To: Kees Cook Cc: Josh Triplett , Eric Biederman , Alexander Viro , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7E11B4000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 15ogta6sz59buofp18tgnzn77xeh1sis X-HE-Tag: 1699398528-475884 X-HE-Meta: U2FsdGVkX1/EnxTX6/R02rdaKyO2SzqUILqWaVthdiznDEMKijpifhsTWCQtbMm7DYDmCsv+xMIUJW5cEeDRIG57WRkKysSzZE9xcHdtmJEHrJBFHa5mYAcp3hD44AfvOe0acFeVk/RvAwG/STfflejbQkPKkMbt7o2y1LLxziUTYOR3/dyzDzNZ21p2/aTukZnHWDlnFo159YHwhcjyUBieYRlEJlZMdG6vOPgBXk1DOiTJ5Jnhcry0BY+oshSK7/FgnEu1TIvC3Q53OP3Q97HxelApLFPSb+VG82uMhR3GaQ2/eUE4sRxJv0qHqxy0RuS+0WM4X8+1x3V+Lh/N6aKeYRi5KtCX5ZdgmN2HR+nW1EHXBOC60XO+16K2/FNN8vT7GeK70fFI7SN1R9GfYTzPebc/vOARLJ6TFJlPxNVFgKViK1FZ7UYx68UI1dou0CXwP9s/hjvuuFNXXoI5vn+0Bn2WVyTugaX9OR6dg2KSpgvyhL/QCMfBZVH5lorW4L/9AESgnT6GUXALAFS0kW/+m93b3a6pTL8NmRRm0JJZ22hht3MZ3gT4rBevxw57gsBof47e1+M5wqDFrkc+l+kwaiM8Oi8LKdGQZ3S+bHt7s/EbYhNDofuI6+lUvsVmWWq5Xuq0+AtRf1sX3LZQM9ucAUqsKRvpbHSgpwjAaDs9mDYzb6QAysJxyIUwcX2iGEvejp9eMZVYFxETbElJkkdYD+xBgXRnVkGnEoJkECN+Y/Ys2E9hbJmQf0+mlpNaMk5gCx3mUKcgYSZM4axb/fi/DXdcQC82pdX1Tuq6zoBkq+jf44bGnTaPue947/etHaoTmMH1bn1vLH6mb4S025RNHCDbqQXsUatafReLl/+UxzxlMRRRe+mEpja32CLUlljqb3I7Cc+RJaz+enRyZcgSsp8idCzv1mWIp5ZKiXL0ca5/dMJx+MDiCuHHrrS7FtS4o3slXk7T3DLO+lU tiwDh5eb F5vIS3Cqahi4vce5TcADBbYxnv237dllJpYoBUc30Q9lig5ej0bBxAQNNlPzfDekMoQNtGi37BZF6xZn7vd117aIY5CYsztpmtB2lVrlsVRl5wfFOb/8RIY+RZZOziJUYC4ZZdoMg+O9mjue1Q/ZARB0oWufLQgyaEKsmlMENy7wX5KKJjyqv0FMVYZ54FT8+7xxe1R6//vCVMmo9gqAUKEWgpSNRcrYTQ1KQBZp/xqKehs1Ev0EBDoNOWdD4rttKEXpB0E3bioUy14f1sOIJaYV4K8a5WO43Jw/RoVEP8ixyAezLaeC89FQFe9ESL/A1tPEf06zmfMUBWbeFUDjRJcMgbu98w+RJLWv1skPAL1WrfKSewxtAgRTkXiIM/eQvLX5xr/8PM6H5Z+kemfoLhm3lom8ilnt95KpBvFCEC3LZF+2PhcKxtJAZ2bV1B5hCbWPpD1qu+h0XNHU4X54Vzw1F30vnbqJ563wRLv4IFXvlPylFUje9nCekUw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, 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 11/7/23, Kees Cook wrote: > On Tue, Nov 07, 2023 at 10:23:16PM +0100, Mateusz Guzik wrote: >> If the patch which dodges second lookup still somehow appears slower a >> flamegraph or other profile would be nice. I can volunteer to take a >> look at what's going on provided above measurements will be done and >> show funkyness. > > When I looked at this last, it seemed like all the work done in > do_filp_open() (my patch, which moved the lookup earlier) was heavier > than the duplicate filename_lookup(). > > What I didn't test was moving the sched_exec() before the mm creation, > which Peter confirmed shouldn't be a problem, but I think that might be > only a tiny benefit, if at all. > > If you can do some comparisons, that would be great; it always takes me > a fair bit of time to get set up for flame graph generation, etc. :) > So I spawned *one* process executing one statocally linked binary in a loop, test case from http://apollo.backplane.com/DFlyMisc/doexec.c . The profile is definitely not what I expected: 5.85% [kernel] [k] asm_exc_page_fault 5.84% [kernel] [k] __pv_queued_spin_lock_slowpath [snip] I'm going to have to recompile with lock profiling, meanwhile according to bpftrace (bpftrace -e 'kprobe:__pv_queued_spin_lock_slowpath { @[kstack()] = count(); }') top hits would be: @[ __pv_queued_spin_lock_slowpath+1 _raw_spin_lock+37 __schedule+192 schedule_idle+38 do_idle+366 cpu_startup_entry+38 start_secondary+282 secondary_startup_64_no_verify+381 ]: 181 @[ __pv_queued_spin_lock_slowpath+1 _raw_spin_lock_irq+43 wait_for_completion+141 stop_one_cpu+127 sched_exec+165 bprm_execve+328 do_execveat_common.isra.0+429 __x64_sys_execve+50 do_syscall_64+46 entry_SYSCALL_64_after_hwframe+110 ]: 206 I did not see this coming for sure. I'll poke around maybe this weekend. -- Mateusz Guzik