From: Paul Moore <paul@paul-moore.com>
To: KP Singh <kpsingh@kernel.org>
Cc: linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
ast@kernel.org, casey@schaufler-ca.com, andrii@kernel.org,
keescook@chromium.org, daniel@iogearbox.net, renauld@google.com,
revest@chromium.org, song@kernel.org
Subject: Re: [PATCH v13 3/5] security: Replace indirect LSM hook calls with static calls
Date: Mon, 8 Jul 2024 10:23:38 -0400 [thread overview]
Message-ID: <CAHC9VhR+6ePv3ce5rMB+42935dsKo6Xok=qzcH6o08ZEx32F+w@mail.gmail.com> (raw)
In-Reply-To: <CACYkzJ6mR9mRGS8Df_U1yTBSamW2VRt4v9-6WQnkbhGDuH5KGQ@mail.gmail.com>
On Mon, Jul 8, 2024 at 9:52 AM KP Singh <kpsingh@kernel.org> wrote:
> On Mon, Jul 8, 2024 at 2:52 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, Jul 8, 2024 at 6:04 AM KP Singh <kpsingh@kernel.org> wrote:
> > > On Sat, Jul 6, 2024 at 6:40 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Fri, Jul 5, 2024 at 3:34 PM KP Singh <kpsingh@kernel.org> wrote:
> > > > > On Fri, Jul 5, 2024 at 8:07 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > On Wed, Jul 3, 2024 at 7:08 PM KP Singh <kpsingh@kernel.org> wrote:
...
> I think you are ignoring my point that BPF does not want to add
> extraneous function calls which at the least result in extra overhead.
I haven't been ignoring you on that point, see my previous comment:
"Correctness first, maintainability second, performance third. That's
my current priority and I feel the maintainability hit doesn't justify
the performance win at this point in time. Besides, we're already
expecting a big performance boost simply by moving to static_calls."
https://lore.kernel.org/linux-security-module/CAHC9VhQQkWxMT3KguOOK7W8cbY-cdeYTJSuh=tSDV4jsqp6s6g@mail.gmail.com/
> You have ignored the fact that BPF LSM never wanted these empty
> callbacks and you still continue to ignore it. Sigh, I will drop it
> now and will propose it as a separate patch so that we can at least
> unblock the static call series.
I didn't comment on that because it isn't very relevant at this point
in time, what matters is the current status quo and the proposed
change. In this particular case I'm not going to debate decisions
made by previous maintainers, my focus is on what we currently have
in-tree and what/how/why people want to change.
You've got a path forward with the bulk of this patchset, if you want
to scuttle it over the last patch in the series that is up to you, but
in my opinion that seems like a lost opportunity.
--
paul-moore.com
next prev parent reply other threads:[~2024-07-08 14:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 8:43 [PATCH v13 0/5] Reduce overhead of LSMs with static calls KP Singh
2024-06-29 8:43 ` [PATCH v13 1/5] kernel: Add helper macros for loop unrolling KP Singh
2024-06-29 8:43 ` [PATCH v13 2/5] security: Count the LSMs enabled at compile time KP Singh
2024-07-03 9:44 ` Rasmus Villemoes
2024-07-03 13:12 ` KP Singh
2024-07-03 14:54 ` Paul Moore
2024-06-29 8:43 ` [PATCH v13 3/5] security: Replace indirect LSM hook calls with static calls KP Singh
2024-07-03 0:07 ` Paul Moore
2024-07-03 16:54 ` KP Singh
2024-07-03 20:56 ` Paul Moore
2024-07-03 22:22 ` KP Singh
2024-07-03 22:52 ` Paul Moore
2024-07-03 23:08 ` KP Singh
2024-07-03 23:44 ` Casey Schaufler
2024-07-04 0:24 ` KP Singh
2024-07-04 1:15 ` KP Singh
2024-07-05 18:07 ` Paul Moore
2024-07-05 19:34 ` KP Singh
2024-07-06 0:17 ` Kees Cook
2024-07-06 4:46 ` Paul Moore
2024-07-06 4:40 ` Paul Moore
2024-07-08 10:04 ` KP Singh
2024-07-08 12:52 ` Paul Moore
2024-07-08 13:52 ` KP Singh
2024-07-08 14:23 ` Paul Moore [this message]
2024-06-29 8:43 ` [PATCH v13 4/5] security: Update non standard hooks to use " KP Singh
2024-07-03 0:07 ` Paul Moore
2024-07-09 12:36 ` KP Singh
2024-07-09 14:51 ` Paul Moore
2024-07-09 16:53 ` Casey Schaufler
2024-07-09 19:05 ` Paul Moore
2024-06-29 8:43 ` [PATCH v13 5/5] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2024-07-03 0:07 ` Paul Moore
2024-07-03 16:55 ` KP Singh
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='CAHC9VhR+6ePv3ce5rMB+42935dsKo6Xok=qzcH6o08ZEx32F+w@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=renauld@google.com \
--cc=revest@chromium.org \
--cc=song@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).