[PATCH v8 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY

[Paul Moore]

On Fri, Dec 8, 2023 at 6:06 PM KP Singh <kpsingh at kernel.org> wrote:
> 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.

The patch itself isn't the problem, it's at the end of the patchset
and easily dropped.  The problem is that you pinged me off-list to try
and get me to move your patchset up the review queue, which isn't
something I appreciate, especially when the feedback I provided
previously was not acted upon ... and yes, I've heard your arguments
about why you continued to carry the patch, but please understand when
I explicitly say "no thank you" to a patch, I want you to drop that
patch; "no thank you" shouldn't be ambiguous.

To summarize:
1. Don't ping me off-list to review patchsets.  I personally find that
incredibly annoying and it guarantees that the patchset gets pushed to
the end of the list (spiteful? sure, but it helps soothe the jagged
nerves of this haggard maintainer).
2. Take maintainer feedback seriously.  If you ignore feedback,
providing a proper review tends to be a waste of time; there are
plenty of other patchsets with authors who are receptive to comments.

Anyway, go enjoy your weekend and just do better next time.  What's
done is done.

-- 
paul-moore.com