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