Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2623736rwb; Mon, 19 Sep 2022 07:41:50 -0700 (PDT) X-Google-Smtp-Source: AMsMyM44DMUaZeolYanLhDytq12fFYkRug11zbKGcK8GIi4F1ZhUbkhshFV4RYt01zfCmi5DFsnM X-Received: by 2002:a05:6402:26d2:b0:451:5a8c:346b with SMTP id x18-20020a05640226d200b004515a8c346bmr15541311edd.424.1663598509851; Mon, 19 Sep 2022 07:41:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663598509; cv=none; d=google.com; s=arc-20160816; b=BPI7KcDdhV/Qk5CCEu8OEYXOIhHpItnfM+tSOlqs2lWlg1VBbKm89pAm29l+2iBD2v 3hE0AP5Bz9+DAZfXOFbJHs/0esDKWuB0v++2PgjEIRFbLRiWceLBUa1Em80pvZkIPcT3 nzMmv6bK9dCf1OE284+WkhhxqlXryMDmPKys7FB97Dv/aCyUi/9ryLQZFzjjkDCbMrlm Ox2uuR9YX02oggri6hlE3FknBegLf7SEXopK7e9i2MP/0eewWId92NMQPn8relEgdu3E whifp0TAqSBW6DExLX6XGdAkGTrfxHCBSKUAM9Xc/yBxrENdV/+UJJ968x7EmDGxyIOx HEmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gMLf/rqQpWC2+XjEGcuSjEkDKbi/0GhYcmxhsgsT9kI=; b=mihPGgaTpwWHDWpkVKPfaTdHiGZW1E4YF5PTAGhE1kcfvrZB2+xO1/MyGBNx5kri0H e/hwKMz0ltiUt+bxeS8Eacaf9FF5ahHO+iHjWLvDojvaHJ2wvXcyHs9igAM6t+Np93UX 8/1SKw0DsurZ0MqW5BBrVyBJ7JhnL3C+uH2a+uoJIQnR+Nol70/W14ojOjYkNdjqFS0U pzmGhrJYeTZXX+J+8BWf3PiBRFSbqRb5/o4o3FBtrpd/fFF4/4o5gZtlyN+nyU9EHUY+ lcR5lPVTlhOT5PRhBMpNag61Iz+TuaQdAMUOz1/vb6X8jDv3NCI/c1Tu306HwFsxMnQF lP0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="HKy/YcOB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qa33-20020a17090786a100b007707c682264si14959097ejc.298.2022.09.19.07.41.24; Mon, 19 Sep 2022 07:41:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="HKy/YcOB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230124AbiISOfB (ORCPT + 99 others); Mon, 19 Sep 2022 10:35:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230161AbiISOex (ORCPT ); Mon, 19 Sep 2022 10:34:53 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 393AB65C7; Mon, 19 Sep 2022 07:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gMLf/rqQpWC2+XjEGcuSjEkDKbi/0GhYcmxhsgsT9kI=; b=HKy/YcOBOeh2qwxkz/0aIlfx1K HE80ZpMr8zuQCCd3t/UE0BntI4h3Mu1TeG+TL6ja45VvI33jmN9jJtZYvzCEOZgvBMqlIiax/uZ86 nN5Y/W4ip8jWmp5Jz/az5yx0PoUwTc5xyRbORDbg+FI20GDX/DbL7e+2VAw3/4gK6vMJpwKAus9To tuQ8JkjszjBlJCP9pYt7n7gssZtw7O34SwbJfd9eEZW2MeOFJaKI25dIcHjlcxcIuba5Si3O3pNCO OzeofN6ymvrV/BcVaYHgci0sQTd73g39ca1pf/UTeCMJQz19ZfTILSjvCaP9IARP2/GAy4NWyZ8/G oa6wH0Og==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oaHrB-004m7e-4e; Mon, 19 Sep 2022 14:34:45 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 070283001F3; Mon, 19 Sep 2022 16:34:41 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id E5B612BAC7765; Mon, 19 Sep 2022 16:34:40 +0200 (CEST) Date: Mon, 19 Sep 2022 16:34:40 +0200 From: Peter Zijlstra To: Kees Cook Cc: Josh Triplett , Eric Biederman , Alexander Viro , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Mel Gorman Subject: Re: [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm Message-ID: 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: <202209161637.9EDAF6B18@keescook> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2022 at 05:11:18PM -0700, Kees Cook wrote: > The interaction with sched_exec() should be no worse (the file is opened > before it in either case), but in reading that function, it talks about > taking the opportunity to move the process to another CPU (IIUC) since, > paraphrasing, "it is at its lowest memory/cache size." But I wonder if > there is an existing accidental pessimistic result in that the process > stack has already been allocated. I am only passingly familiar with how > tasks get moved around under NUMA -- is the scheduler going to move > this process onto a different NUMA node and now it will be forced to > have the userspace process stack on one node and the program text and > heap on another? Or is that totally lost in the noise? Probably noise; text is going to be a crap-shoot anyway due to DSOs only having a single copy in the page-cache. And the stack will be relatively small at this point and also, numa-balance can migrate those pages around if they matter. > More specifically, I was wondering if processes would benefit from having > sched_exec() moved before the mm creation? Can't hurt I think.