2021-09-17 15:50:22

by Kees Cook

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] gcc-plugins/structleak: add makefile var for disabling structleak

On Thu, Sep 16, 2021 at 11:10:59PM -0700, Brendan Higgins wrote:
> KUnit and structleak don't play nice, so add a makefile variable for
> enabling structleak when it complains.
>
> Co-developed-by: Kees Cook <[email protected]>

For a C-d-b, also include a S-o-b:

Signed-off-by: Kees Cook <[email protected]>

But otherwise, yes, this is good. :)

-Kees

> Signed-off-by: Brendan Higgins <[email protected]>
> ---
> scripts/Makefile.gcc-plugins | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index 952e46876329a..4aad284800355 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -19,6 +19,10 @@ gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF) \
> += -fplugin-arg-structleak_plugin-byref
> gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) \
> += -fplugin-arg-structleak_plugin-byref-all
> +ifdef CONFIG_GCC_PLUGIN_STRUCTLEAK
> + DISABLE_STRUCTLEAK_PLUGIN += -fplugin-arg-structleak_plugin-disable
> +endif
> +export DISABLE_STRUCTLEAK_PLUGIN
> gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) \
> += -DSTRUCTLEAK_PLUGIN
>
> --
> 2.33.0.464.g1972c5931b-goog
>

--
Kees Cook


2021-09-29 20:29:46

by Brendan Higgins

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] gcc-plugins/structleak: add makefile var for disabling structleak

On Fri, Sep 17, 2021 at 8:48 AM Kees Cook <[email protected]> wrote:
>
> On Thu, Sep 16, 2021 at 11:10:59PM -0700, Brendan Higgins wrote:
> > KUnit and structleak don't play nice, so add a makefile variable for
> > enabling structleak when it complains.
> >
> > Co-developed-by: Kees Cook <[email protected]>
>
> For a C-d-b, also include a S-o-b:
>
> Signed-off-by: Kees Cook <[email protected]>
>
> But otherwise, yes, this is good. :)

Yeah, I know that's necessary for the patch to be accepted, but in
this case, I don't think your original version of this (it wasn't
actually a patch) had a S-o-b on it, so I didn't want to say that you
had signed off on something that you didn't.

I have run into this situation before and handled it this way -
letting the co-developer sign off on the list. Is this something I
should avoid in the future?

In any case, I will resubmit this now that I have your S-o-b.

Thanks!