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 9AD98C4332F for ; Wed, 8 Nov 2023 19:25:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F4D98D00C3; Wed, 8 Nov 2023 14:25:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A30E8D0073; Wed, 8 Nov 2023 14:25:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAC198D00C3; Wed, 8 Nov 2023 14:25:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DC5A48D0073 for ; Wed, 8 Nov 2023 14:25:38 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A0E5C1CB931 for ; Wed, 8 Nov 2023 19:25:38 +0000 (UTC) X-FDA: 81435766356.13.FA50DFC Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf21.hostedemail.com (Postfix) with ESMTP id CC2F91C0006 for ; Wed, 8 Nov 2023 19:25:36 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=GFBiBzI3; spf=pass (imf21.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.170 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699471536; 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=uWUjp1kT4QadWCPtlP2kQwh/Ipvn+sm+hKLdkqyjovw=; b=lF/g/HlYcWJT/UpxWqDsEygzcGQEYF69FdJakYJNFys9L+C/Es+wcaZTppbZpS0z7dDqoS 3Y2GeYpeV7yP9F2BgsXDVkjqEIdunP2GXjm7O+X2dJza7g25OSjsl+eCoT6MYVGVgD9nlD WlrWTYaL+zj4bUk7sNsaAe3cPKSTQZg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699471536; a=rsa-sha256; cv=none; b=Kj7/fu59v4uuvhIjONiLySOajDSJBbwkpLwBXnL9tFoxQn0XVlsG1RgDaMwAZ3czDjoozd 5qFWwTGhWXVmztXbxMakcmz3++XIX9T14DlHQwjqm2upmkF6CyuwYxJZ1ZxT/rujPegEye pmiom7O1XgiDCtaWGBhY3/trxZyWQgA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=GFBiBzI3; spf=pass (imf21.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.170 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1cc9b626a96so43635225ad.2 for ; Wed, 08 Nov 2023 11:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1699471535; x=1700076335; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uWUjp1kT4QadWCPtlP2kQwh/Ipvn+sm+hKLdkqyjovw=; b=GFBiBzI3ZiTTlU+iu7oRguFQOZI7pj+HAyRDFnaCRfi7zw+YmOH2h7y+fHoL9P5Pb9 Ppmb/fMSHRr2QbFgRa63u2xtbUDFxDvAhlpfp7W9IyroALu6PPyRoAv53ej/uHaSzB8E ZD73mISzemWQuhyvf/QP7wkfAvMrTWC8KRJOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699471535; x=1700076335; 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 :message-id:reply-to; bh=uWUjp1kT4QadWCPtlP2kQwh/Ipvn+sm+hKLdkqyjovw=; b=Lp9zi00Y6HhQb5MQ5BYtf6wcspMcZHL46ZuemfD6hc6D6bDjmnVTOenvKd9ZFGZNpd cdHBFO0NEj6aUbyK9YEFWWonYMMccY8s3A0Owr9ByhEslfm4yMiNNjqhhqitQZbEoV2S FjLEJubne+/1mZ6/nR1P7el1wYMqLI50x/ZcAz5iwvEeafbXzgSLY9ekpNCMlr0XLTII IRKWV+wsvZORnQXUHAgJIUBoPnoFsZkg8q0RXIZRO3uUMt6+jV7DVHKwJak/xv0XtqXm jUifSUR6JxGIKxKFPmShudN/l6fqHUZqAT5rZWlYK7Gfrt0FIAXvkIUQ8qrUw6YbIQsE FdcA== X-Gm-Message-State: AOJu0YwKQbyOYIK0wL4oqW96F6KpKz2NebYo0KQcckOV/wSSdQvOswi5 n5T4Wz7IdAPbqO/4Yj8+0aqkqw== X-Google-Smtp-Source: AGHT+IFWQvD64GPyRJT6Hb58vipaf+YJS2on70JhtNQdeZqsPwpz2F6tsQ6yRwN8BcF7cB5aQ/N19w== X-Received: by 2002:a17:902:ecc6:b0:1cc:4072:22c6 with SMTP id a6-20020a170902ecc600b001cc407222c6mr3552930plh.24.1699471535672; Wed, 08 Nov 2023 11:25:35 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id ix22-20020a170902f81600b001b8a00d4f7asm2097005plb.9.2023.11.08.11.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 11:25:34 -0800 (PST) Date: Wed, 8 Nov 2023 11:25:34 -0800 From: Kees Cook To: Mateusz Guzik Cc: Kees Cook , Josh Triplett , 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: <202311081123.391A316@keescook> References: <5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org> <202311071228.27D22C00@keescook> <20231107205151.qkwlw7aarjvkyrqs@f> <202311071445.53E5D72C@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 999rg6wf5g7gj6wf9pp4sq36ut5sgrzx X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: CC2F91C0006 X-Rspam-User: X-HE-Tag: 1699471536-833940 X-HE-Meta: U2FsdGVkX1/rwSdmotxRwezJjx6tplk2GWW+21I21LZce+sdG2eHO2B38pxizjqJWBekA5g1loeZmTEYTYcjWolm0MNkvEja83dWKgRp9Hzd5qtZEyOgqsXrr7WE8BLwF3Oobq/OX4/lCqYcQ3VeIYpp1F/3PWoma4hndG2xvziBfKBTXu8KxY5LcLPCL9il5tt08ZJPtpmLpYgeSh5i5C4EKoO5XzCC+uMcrohag5c2imB2TtXthRcwSMfW860sdj6J3gCrdOq561HpdgUX9nuA++5wtHY+hiqrlZO1+1wNADUwaV3hOP2SdMZGu0Wef8RuuDx8lC52jEdJ1zyO3VkFcO5BzScmBjXEN7/CaqvGcpBt04rz1cVKbs1b1mHZvryblFtwjVbLOa5qLzlugQjSEf2MEyohZr67a7T9PdJBUcADuQX26dimnXf1BTm1ROI0nq0GGpwqxA2mBJcUolLeBnShC4xU6rOB5KS/ZaLONhWrlrfgDid/1pXiiT3S3+5E1JGSKU0DYFiAWxTM6KxCiod7xJdGBO3eGdFElhdNKgJnOoV4YGtQEW8fZz3v72jWBSwbul5eHrknly8Brcm/paZFF2UFgpn+MgtGdDVZHI31WmUOD1+8uZmEzTmpf3l4mtiVZ6Ea7vSsp1YcVxAqi1SMCfYUjjq/5hUnfTpNEHqhULuaHUSRDnz/x+a1wHdQFM6wu/2VMawgG/nehvvk94XlA/drSWEUwJgjrRTM9JPai6ESul3OSvEkag9YeGAFLNWa5LnWHnZH4/Yt0FPZZ77qIXaf2SqxUC4FjjsGXpxYB2VGsrprwIPGGzMrzO4p6Bh4hrxzvjaRB1U4SD7Hjdi0jAWPjZvLSECn0CS8MEerFY/B+wSMyIiOeXGU5S5GmLBwAeAqBYhs11aQBtLXuFTGrg9OGQh8uvJ/6WlFVDUD/nGwXAeOhwcQkdpPHLZpPah1H5tDGlmby7P xML2FDKg R4KLXnMqGe599rfLgfFtBnWyKru5f1LPqSS7ph2j9Glg+ZQ3etzwh0P7y1ALPDv+hgvOESxy0K42d/mEosWkvgBKArYECQx/gZYzrlVIu0woUMnFe4YvMl9zlmgADmSwyum34N2nzN8mx+eSOoXs6FVV/wLUMptX7xOFw3xdDHz++hZ3SQIBTudkFiG2LwKOohxwnPIPY5bGkRaktrnqGbkEXVGa1lB7D/8t86LtAU/jIuCPbDI3ehE5/FZbvHtXZFXSKYDXPjAV9FS92VdBkEtKRSl3p3dajyZIMyRf9hd75A/aOyhqdmn8PvIDSWp+SEiM/0XM6UEHKNzqY3zUtx4W/wI3oetYM9nko X-Bogosity: Ham, tests=bogofilter, spamicity=0.000629, 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 Wed, Nov 08, 2023 at 01:03:33AM +0100, Mateusz Guzik wrote: > [...] > >>@[ > >> __pv_queued_spin_lock_slowpath+1 > >> _raw_spin_lock_irq+43 > >> wait_for_completion+141 > >> stop_one_cpu+127 > >> sched_exec+165 > > > > There's the suspicious sched_exec() I was talking about! :) > > > > I think it needs to be moved, and perhaps _later_ instead of earlier? > > Hmm... > > > > I'm getting around 3.4k execs/s. However, if I "taskset -c 3 > ./static-doexec 1" the number goes up to about 9.5k and lock > contention disappears from the profile. So off hand looks like the > task is walking around the box when it perhaps could be avoided -- it > is idle apart from running the test. Again this is going to require a > serious look instead of ad hoc pokes. Hm, that is pretty interesting. I'll see if I can go find the original rationale for adding sched_exec() in there... > Side note I actually read your patch this time around instead of > skimming through it and assuming it did what I thought. > > do_filp_open is of course very expensive and kmalloc + kfree are slow. > On top of it deallocating a file object even after a failed open was > very expensive due to delegation to task_work (recently fixed). > > What I claim should be clear-cut faster is that lookup as in the > original patch and only messing with file allocation et al if it > succeeds. I'm less familiar with the VFS guts here -- I'm open to alternatives! :) -- Kees Cook