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 B5428ECAAA1 for ; Mon, 19 Sep 2022 20:02:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39428940007; Mon, 19 Sep 2022 16:02:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 343596B0072; Mon, 19 Sep 2022 16:02:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20B12940007; Mon, 19 Sep 2022 16:02:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0E2166B0071 for ; Mon, 19 Sep 2022 16:02:55 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DDAF51A0B68 for ; Mon, 19 Sep 2022 20:02:54 +0000 (UTC) X-FDA: 79929908268.06.880CBFB Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf26.hostedemail.com (Postfix) with ESMTP id 5951914001D for ; Mon, 19 Sep 2022 20:02:54 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id w2so708954pfb.0 for ; Mon, 19 Sep 2022 13:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=eXOyFyEzKdpniG5U/G+Dwx8iZBCxSfFUM/Yw73mc+so=; b=ZlzZ84XF8ZFDq70FjCYSSmOLDhZeLkHYK4bUuKiFjK50Eo6AZzVjif2v7zvvKVOTOv SuDuMxamu9LbPcESelBkSAjw5LssTVjFXWWZ490uIULYHfDkZPzwnFaHcHhlGO8bVSH/ U32wY7Cn4gV/VB/Dqlvcby+ZUv7RPspDGimHM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=eXOyFyEzKdpniG5U/G+Dwx8iZBCxSfFUM/Yw73mc+so=; b=5t9z3n5vLHmly8/KweBeaqevrtv2+gts8zNsPjnMjFBWku3PS+H2zzKpsNCbB0Ektp Agl8lmoXsBV2+aOYRZnT2DNnOIQB7Re3MRXGtb8EF5lILJN4O/ntj+0+zF5209Fl+ijz NdK7LowUedvueyAnb1jurUOpPLhIr4MDH8boAAde+peCh4QMWRM6KR4vQ158HRHt/vLp VZ5MV8FBZNQ/Tv73brMjE5Hr62JAZ1c8qK7mRcUTOnzjg77RcFpf92flLKYdPtAHBfTG WCds0e8PbgnxuQKZJmRLvPXwNBswTse7AxXaUcuGzcD34bp2SOXhV26CnwBdWjrWj1ee VldA== X-Gm-Message-State: ACrzQf14zAljEnMdCvxG8E/E7mg93tnmGjlXDVgH453szwPVwyMQtP6D IPNo1dhzPK0uvXDnprp7wT7SYKlPWJ365w== X-Google-Smtp-Source: AMsMyM6U70M8NWqkoA6aAkbcsmk1Br3IMj+BnnvH8aMlRSS4P44R+pMDuyh1o2jpsQuXF9hD0H2Okg== X-Received: by 2002:a62:fb18:0:b0:548:9dff:89da with SMTP id x24-20020a62fb18000000b005489dff89damr20518686pfm.23.1663617773359; Mon, 19 Sep 2022 13:02:53 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id d11-20020a62f80b000000b0053e85a4a2c9sm9446500pfh.5.2022.09.19.13.02.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Sep 2022 13:02:52 -0700 (PDT) Date: Mon, 19 Sep 2022 13:02:51 -0700 From: Kees Cook To: Josh Triplett Cc: Peter Zijlstra , Eric Biederman , Alexander Viro , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm Message-ID: <202209191256.893576D4@keescook> References: <5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org> <202209160727.5FC78B735@keescook> <202209161637.9EDAF6B18@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZlzZ84XF; spf=pass (imf26.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.173 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663617774; a=rsa-sha256; cv=none; b=p0VQv36vqVVCq9Q5mZXwjgw3NWBFH6xptqMhrlBgFwZoalpXaCcR5ncSmDynnfWhqgqHBs eNbjd51da7Wk3FihgF7VRCdRmXE0Q5ht5P9OPMESzd96MKBBh19ui838dK31BtzelSbRB3 /bvVVCZdSSm3gKQR2vFC8NdETZxwTVY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663617774; 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=eXOyFyEzKdpniG5U/G+Dwx8iZBCxSfFUM/Yw73mc+so=; b=IGpvZFE8RfCaTNjugw96+sfHRkYU+5f9lN1uWVfautvVWzfgUuXp9u3b5TdsS7//R6hj9d +6zcURkTNe+PjVPdE5gtz+SezM+lOwxUbjLu7CjyRMFrtPtH07Nq4cxsXCGsPFk0ly5sFe t76VH3/gpQg3h4t73a6M9s1kCQFEZ7w= X-Rspam-User: X-Rspamd-Queue-Id: 5951914001D Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZlzZ84XF; spf=pass (imf26.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.173 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: q9jr3jqy6gi7u3fa59nq6w9x7i75m3iz X-Rspamd-Server: rspam04 X-HE-Tag: 1663617774-341366 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: On Sat, Sep 17, 2022 at 01:50:24AM +0100, Josh Triplett wrote: > On Fri, Sep 16, 2022 at 05:11:18PM -0700, Kees Cook wrote: > > I don't like the idea of penalizing the _succeeding_ case, though, which > > happens if we do the path walk twice. So, I went and refactoring the setup > > order, moving the do_open_execat() up into alloc_bprm() instead of where > > it was in bprm_exec(). The result makes it so it is, as you observed, > > before the mm creation and generally expensive argument copying. The > > difference to your patch seems to only be the allocation of the file > > table entry, but avoids the double lookup, so I'm hoping the result is > > actually even faster. > > Thanks for giving this a try; I'd wondered how feasible it would be to > just do one lookup. > > However, on the same test system with the same test setup, with your > refactor it seems to go slower: > fork/execvpe: 38087ns > fork/execve: 33758ns > > For comparison, the previous numbers (which I re-confirmed): > > Without fast-path: > fork/execvpe: 49876ns > fork/execve: 32773ns > > With my original separate-lookup fast-path: > fork/execvpe: 36890ns > fork/execve: 31551ns Hmm, this shows as slower in the *normal* case, which I find rather surprising -- it's the same work, just reordered. Can you post a URL to your tests? I'd like to reproduce this and maybe throw perf at it as well. > I tried several runs of each, and I seem to get reasonably consistent > results. > > My test program just creates a pipe once, then loops on > clock_gettime/fork/execvpe/read, with the spawned child process doing > clock_gettime/write/exit (in asm to minimize overhead). The test PATH is > PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. with > the test program in the current directory. I'm also curious about less synthetic testing. It'd be nice to see real workloads with these changes, etc. -- Kees Cook