lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 14 Apr 2020 11:16:45 -0400
From:   Sasha Levin <>
To:     Or Gerlitz <>
Cc:     Greg KH <>,
        Jakub Kicinski <>,
        Stable <>,
        Linux Netdev List <>,
        Saeed Mahameed <>,
        David Miller <>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for

On Tue, Apr 14, 2020 at 05:38:32PM +0300, Or Gerlitz wrote:
>On Tue, Apr 14, 2020 at 2:09 PM Greg KH <> wrote:
>> On Tue, Apr 14, 2020 at 01:22:59PM +0300, Or Gerlitz wrote:
>> > IMHO - I think it should be the other way around, you should get approval
>> > from sub-system maintainers to put their code in charge into auto-selection,
>> > unless there's kernel summit decision that says otherwise, is this documented
>> > anywhere?
>> No, we can't get make this a "only take if I agree" as there are _many_
>> subsystem maintainers who today never mark anything for stable trees, as
>> they just can't be bothered.  And that's fine, stable trees should not
>> take up any extra maintainer time if they do not want to do so.  So it's
>> simpler to do an opt-out when asked for.
>OK, but I must say I am worried from the comment made here:
>"I'm not sure what a fixes tag has to do with inclusion in a stable tree"
>This patch
>(A) was pushed to -next and not -rc kernel

Fixes can (and should) come in during a merge window as well. They are
not put on hold until the -rc releases.

>(B) doesn't have fixes tag

In the 4.19 stable tree there are 3962 commits explicitly tagged for
stable, only 2382 of them have a fixes tag. 

>(C) the change log state clearly that what's being "fixed"
>can't be reproduced on any earlier kernel [..] "only possible
>to reproduce with next commit in this series"
>but it was selected for -stable -- at least if the fixes tag was used
>as gating criteria, this wrong stable inclusion could have been eliminated

Are you suggesting that a commit without a fixes tag is never a fix?


Powered by blists - more mailing lists