Re: [GIT PULL] execve updates for v6.8-rc1

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Josh Triplett <josh@joshtriplett.org>,
	Kees Cook <kees@kernel.org>,  Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org,
	 Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [GIT PULL] execve updates for v6.8-rc1
Date: Thu, 11 Jan 2024 09:42:35 -0800	[thread overview]
Message-ID: <CAHk-=wi-aMO1GuN1odOz4MZksMNECVdrORuXKfqSS9DoTx0yDg@mail.gmail.com> (raw)
In-Reply-To: <20240111100501.GU1674809@ZenIV>

On Thu, 11 Jan 2024 at 02:05, Al Viro <viro@zeniv.linux.org.uk> 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