Re: [PATCH v8 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 8, 2023 at 11:05 PM Kees Cook <keescook@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/

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.


>
> Agreed. :) Anyway, when you do review it, I think you can just ignore
> patch 5, and if a v9 isn't needed, a brand new patch for that logic can
> be created later.
>
> --
> Kees Cook





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux