[PATCH v13 3/5] security: Replace indirect LSM hook calls with static calls

[Paul Moore]

On Mon, Jul 8, 2024 at 9:52 AM KP Singh <kpsingh at kernel.org> wrote:
> On Mon, Jul 8, 2024 at 2:52 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Mon, Jul 8, 2024 at 6:04 AM KP Singh <kpsingh at kernel.org> wrote:
> > > On Sat, Jul 6, 2024 at 6:40 AM Paul Moore <paul at paul-moore.com> wrote:
> > > > On Fri, Jul 5, 2024 at 3:34 PM KP Singh <kpsingh at kernel.org> wrote:
> > > > > On Fri, Jul 5, 2024 at 8:07 PM Paul Moore <paul at paul-moore.com> wrote:
> > > > > > On Wed, Jul 3, 2024 at 7:08 PM KP Singh <kpsingh at 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