[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMn1gO7S++yR4=DjrPZU_POAHP8Pfxaa3P2Cy__Ggu+kN9pqBA@mail.gmail.com>
Date: Wed, 23 Feb 2022 14:30:48 -0800
From: Peter Collingbourne <pcc@...gle.com>
To: Marco Elver <elver@...gle.com>
Cc: Miaohe Lin <linmiaohe@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Andrey Konovalov <andreyknvl@...il.com>,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kasan: update function name in comments
On Mon, Feb 21, 2022 at 3:15 AM Marco Elver <elver@...gle.com> wrote:
>
> On Sat, 19 Feb 2022 at 03:00, Miaohe Lin <linmiaohe@...wei.com> wrote:
> >
> > On 2022/2/19 9:24, Peter Collingbourne wrote:
> > > The function kasan_global_oob was renamed to kasan_global_oob_right,
> > > but the comments referring to it were not updated. Do so.
> > >
> > > Link: https://linux-review.googlesource.com/id/I20faa90126937bbee77d9d44709556c3dd4b40be
> > > Signed-off-by: Peter Collingbourne <pcc@...gle.com>
> > > Fixes: e5f4728767d2 ("kasan: test: add globals left-out-of-bounds test")
> >
> > This Fixes tag is unneeded.
> >
> > Except the above nit, this patch looks good to me. Thanks.
> >
> > Reviewed-by: Miaohe Lin <linmiaohe@...wei.com>
>
> Reviewed-by: Marco Elver <elver@...gle.com>
>
> And yes, the Fixes tag should be removed to not have stable teams do
> unnecessary work.
I thought that Cc: stable@...r.kernel.org controlled whether the patch
is to be taken to the stable kernel and Fixes: was more of an
informational tag. At least that's what this seems to say:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight
> +Cc'ing missing mailing lists (use get_maintainers.pl - in particular,
> LKML is missing, which should always be Cc'd for archival purposes so
> that things like b4 can work properly).
get_maintainers.pl tends to list a lot of reviewers so I try to filter
it to only the most important recipients or only use it for
"important" patches (like the uaccess logging patch). It's also a bit
broken in my workflow --
https://lore.kernel.org/all/20210913233435.24585-1-pcc@google.com/
fixes one of the problems but there are others.
Doesn't b4 scan all the mailing lists? So I'd have imagined it
wouldn't matter which one you send it to.
Peter
Powered by blists - more mailing lists