From: Kees Cook <keescook@chromium.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>,
Eric Biederman <ebiederm@xmission.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
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
Date: Tue, 7 Nov 2023 14:50:01 -0800 [thread overview]
Message-ID: <202311071445.53E5D72C@keescook> (raw)
In-Reply-To: <CAGudoHFsqMPmVvaV7BebGkpkw=pSQY8PLdB-1S3W5NpYh6trmA@mail.gmail.com>
On Tue, Nov 07, 2023 at 10:23:16PM +0100, Mateusz Guzik wrote:
> If the patch which dodges second lookup still somehow appears slower a
> flamegraph or other profile would be nice. I can volunteer to take a
> look at what's going on provided above measurements will be done and
> show funkyness.
When I looked at this last, it seemed like all the work done in
do_filp_open() (my patch, which moved the lookup earlier) was heavier
than the duplicate filename_lookup().
What I didn't test was moving the sched_exec() before the mm creation,
which Peter confirmed shouldn't be a problem, but I think that might be
only a tiny benefit, if at all.
If you can do some comparisons, that would be great; it always takes me
a fair bit of time to get set up for flame graph generation, etc. :)
-Kees
--
Kees Cook
next prev parent reply other threads:[~2023-11-07 22:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 13:41 [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm Josh Triplett
2022-09-16 14:38 ` Kees Cook
2022-09-16 20:13 ` Josh Triplett
2022-09-17 0:11 ` Kees Cook
2022-09-17 0:50 ` Josh Triplett
2022-09-19 20:02 ` Kees Cook
2022-10-01 16:01 ` Josh Triplett
2022-09-19 14:34 ` Peter Zijlstra
2022-09-22 7:27 ` [fs/exec.c] 0a276ae2d2: BUG:workqueue_lockup-pool kernel test robot
2022-09-22 7:27 ` kernel test robot
2023-11-07 20:30 ` [PATCH] fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm Kees Cook
2023-11-07 20:51 ` Mateusz Guzik
2023-11-07 21:23 ` Mateusz Guzik
2023-11-07 22:50 ` Kees Cook [this message]
2023-11-07 23:08 ` Mateusz Guzik
2023-11-07 23:39 ` Kees Cook
2023-11-08 0:03 ` Mateusz Guzik
2023-11-08 19:25 ` Kees Cook
2023-11-08 19:31 ` Kees Cook
2023-11-08 19:35 ` Mateusz Guzik
2023-11-09 0:17 ` Eric W. Biederman
2023-11-09 12:21 ` Mateusz Guzik
2023-11-10 5:26 ` Eric W. Biederman
2023-11-07 20:37 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202311071445.53E5D72C@keescook \
--to=keescook@chromium.org \
--cc=ebiederm@xmission.com \
--cc=josh@joshtriplett.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mjguzik@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.