[PATCH v8 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY

KP Singh kpsingh at kernel.org
Fri Dec 8 23:06:32 UTC 2023


On Fri, Dec 8, 2023 at 11:59 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, Dec 8, 2023 at 5:40 PM KP Singh <kpsingh at kernel.org> wrote:
> > On Fri, Dec 8, 2023 at 11:05 PM Kees Cook <keescook at chromium.org> wrote:
> > > On Fri, Dec 08, 2023 at 04:43:57PM -0500, Paul Moore wrote:
> > > > On Fri, Dec 8, 2023 at 4:13 PM Kees Cook <keescook at chromium.org> wrote:
> > > > > On Fri, Dec 08, 2023 at 03:51:47PM -0500, Paul Moore wrote:
> > > > > > Hopefully by repeating the important bits of the conversation you now
> > > > > > understand that there is nothing you can do at this moment to speed my
> > > > > > review of this patchset, but there are things you, and KP, can do in
> > > > > > the future if additional respins are needed.  However, if you are
> > > > > > still confused, it may be best to go do something else for a bit and
> > > > > > then revisit this email because there is nothing more that I can say
> > > > > > on this topic at this point in time.
> > > > >
> > > > > I moved to the list because off-list discussions (that I got involuntarily
> > > > > CCed into and never replied to at all) tend to be unhelpful as no one else
> > > > > can share in any context they may provide. And I'm not trying to rush
> > > > > you; I'm trying to make review easier.
> > > >
> > > > From my perspective whatever good intentions you had at the start were
> > > > completely lost when you asked "What's the right direction forward?"
> > > > after I had already explained things multiple times *today*.  That's
> > > > the sort of thing that drives really bothers me.
> > >
> > > Okay, I understand now. Sorry for frustrating you! By "way forward",
> > > I meant I didn't understand how to address what looked like conflicting
> > > feedback. I think my confusion was over separating the goal ("this
> > > feature should be automatically enabled when it is known to be useful")
> > > from an interpretation of earlier feedback as "I don't want a CONFIG [that
> > > leaves this up to the user]", when what you really wanted understood was
> > > "I don't want a CONFIG *ever*, regardless of whether it picks the correct
> > > setting automatically".
> > >
> > > >
> > > > > While looking at the v8 again I
> > > > > saw an obvious problem with it, so I commented on it so that it's clear
> > > > > to you that it'll need work when you do get around to the review.
> > > >
> > > > That's fair.  The Kconfig patch shouldn't have even been part of the
> > > > v8 patchset as far as I'm concerned, both because I explained I didn't
> > > > want to merge something like that (and was ignored) and because it
> > > > doesn't appear to do anything.  From where I sit this was, and
> > > > remains, equally parts comical and frustrating.
> >
> >
> > Paul, as I said I will include it in v3 and we can drop it if that's
> > the consensus.
> >
> > https://lore.kernel.org/bpf/CACYkzJ7KBBJV-CWPkMCqT6rK6yVEOJzhqUjvWzp9BAm-rx3Gsg@mail.gmail.com/
> >
> > Following that, I received Acks on the patch, so I kept it. I wasn't
> > sure if this was going to be perceived as "ignoring your feedback".
> > Definitely not my intention. I was just giving an option for folks who
> > wanted to test the patch so that we get the defaults right. I am
> > totally okay with us dropping the config patch.
>
> <heavy sarcasm>I'm glad you're okay with dropping a patch I said I
> wasn't going to merge three months ago.  I'm also glad you're okay
> with dropping a patch that does absolutely nothing.</heavy sarcasm>

The patch does something (it's in the patch description). But it's
something that you don't think is worth tweaking and that's fine.

>
> Come on KP, you're better than this.  Continuing to carry a patch that
> I've said I'm not going to merge only creates confusion about what
> will be accepted/supported (see today's exchange as a perfect
> example).  There is no need to keep the patch going "for reference",

Okay, I won't. I honestly did not think this was that big a deal and
would bother you so much and, please do assume good intent, I did not
want to create confusion here.

- KP

> to record ACKs, or anything similar to that; all the reviews, ACKs,
> etc. happened on a public list so we have that covered from a
> historical perspective.
>
> I suppose there is a worthy offshoot discussion about consensus and
> maintainer discretion, but I'm too tired and annoyed to give that
> discussion the attention it deserves, so let's just say that when I
> say stuff like I did back in the v2 patchset that should be taken as a
> "regardless of what consensus there may be, I'm not going to merge
> this patch."
>
> --
> paul-moore.com



More information about the Linux-security-module-archive mailing list