On Mon, Jul 8, 2024 at 9:52 AM KP Singh [off-list ref] wrote:

On Mon, Jul 8, 2024 at 2:52 PM Paul Moore [off-list ref] wrote:

quoted

On Mon, Jul 8, 2024 at 6:04 AM KP Singh [off-list ref] wrote:

quoted

On Sat, Jul 6, 2024 at 6:40 AM Paul Moore [off-list ref] wrote:

quoted

On Fri, Jul 5, 2024 at 3:34 PM KP Singh [off-list ref] wrote:

quoted

On Fri, Jul 5, 2024 at 8:07 PM Paul Moore [off-list ref] wrote:

quoted

On Wed, Jul 3, 2024 at 7:08 PM KP Singh [off-list ref] 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/ (local)

 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