From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D17F524C0 for ; Thu, 11 Jan 2024 17:42:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hGPI6AfT" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-50ea8fbf261so6546843e87.2 for ; Thu, 11 Jan 2024 09:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1704994973; x=1705599773; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wE5ZuBbJGZvm1+tXWIds9qs34jd9tFXTLXg/uz/Nfmc=; b=hGPI6AfTrIFUGvVvZYrrxh9N00hZDXya3xpRJAPAXO60QdOMZbQf8Qcc8gjXc/mRMs 907GFs9/cSTUIXbbWpVL2bdmy2fILqJRdwkpXUvqHhHDNPZIhXY1N9fzFG3QhZwPI3pY ZW+bhOMsf8wkcJQ65zXjA/iNFYgt+j1qhJ9IY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704994973; x=1705599773; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wE5ZuBbJGZvm1+tXWIds9qs34jd9tFXTLXg/uz/Nfmc=; b=Uc7maWdLCL6NGM7NO6uStML8UxKgC35CBMgwxraKt113i2xZJ4B698x47MjpHncz7M zGeQTN/QqiAr5XxMFB1kZ9BQwNtymgbK/hdJkm3rw0G6R79nQJBr0Dt5tEwz4JKFB+io yncIs1fdZyjyCI25t9in3ZyhIl5Lvyg+F6jyH+eyUw2oEz+OpePJmk+5oHnDNidMxw78 LUMrcObwgE2ThhU7ewV0R6MBrhgtDuB7qVCTtzCNjLIYZPe9KPiCzkexsuvzwst9+01N CtsL8Rr+tdS2zeYjpGfLMXKEez08zaCMeCqbDGRL1khyNFOBkMMXd9zg/zZBkAXLEApb NDGQ== X-Gm-Message-State: AOJu0YyPK8xd1ubGkKbex8SripfHpkIXgu6Pu9Py7FkrGzf9QUY50Q/y 3NDii5zbz6KmgqDNQtQyV3HHgB5PenK+hVupiuCTJa4e1RvTs9Jm X-Google-Smtp-Source: AGHT+IGXTlOHRo9UWHjWMTsf6A3+O6Ebyw1rWzx/Hzqj+uBWyl1KFTDBBINeUyUvNb1CuAjhVESPzw== X-Received: by 2002:a05:6512:3e06:b0:50e:35ef:681f with SMTP id i6-20020a0565123e0600b0050e35ef681fmr25876lfv.139.1704994973075; Thu, 11 Jan 2024 09:42:53 -0800 (PST) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id y11-20020a170906524b00b00a233515c39esm827172ejm.67.2024.01.11.09.42.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jan 2024 09:42:52 -0800 (PST) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a2ac304e526so489767766b.0 for ; Thu, 11 Jan 2024 09:42:52 -0800 (PST) X-Received: by 2002:a17:906:318a:b0:a2b:9580:c447 with SMTP id 10-20020a170906318a00b00a2b9580c447mr11535ejy.110.1704994971881; Thu, 11 Jan 2024 09:42:51 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <202401081028.0E908F9E0A@keescook> <20240111094711.GT1674809@ZenIV> <20240111100501.GU1674809@ZenIV> In-Reply-To: <20240111100501.GU1674809@ZenIV> From: Linus Torvalds Date: Thu, 11 Jan 2024 09:42:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] execve updates for v6.8-rc1 To: Al Viro Cc: Josh Triplett , Kees Cook , Kees Cook , linux-kernel@vger.kernel.org, Alexey Dobriyan Content-Type: text/plain; charset="UTF-8" On Thu, 11 Jan 2024 at 02:05, Al Viro wrote: > > Something like (completely untested) delta below, perhaps? No, this looks horrible. This doesn't actually get rid of the early filp allocation for execve(), it only seems to get rid of the repeated allocation for when the RCU lookup fails. And *that* is much easier to get rid of differently: just do the file allocation in do_filp_open(), instead of path_openat. We'd need to have some way to make sure that there is no left-over crud from the RCU path into the next stage, but that doesn't look bad. So the "path_openat() allocates filp on each invocation" looks fairly easy. It's the "don't allocate filp until you actually need it" that looks nasty. And yes, atomic_open() is part of the problem, but so is the fact that wee end up saving some flags in the filp early. Linus