netdev - Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAJ3xEMhnXZB-HU7aL3m9A1N_GPxgOC3U4skF_qWL8z3wnvSKPw@mail.gmail.com>
Date:   Tue, 14 Apr 2020 17:38:32 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Sasha Levin <sashal@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
        Stable <stable@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

On Tue, Apr 14, 2020 at 2:09 PM Greg KH <gregkh@...uxfoundation.org> 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

(B) doesn't have 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