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: <20200415053101.GC1239315@unreal>
Date:   Wed, 15 Apr 2020 08:31:01 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org, Edward Cree <ecree@...arflare.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Stable <stable@...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 Wed, Apr 15, 2020 at 12:50:09AM +0200, Michal Kubecek wrote:
> On Tue, Apr 14, 2020 at 08:37:18PM +0300, Leon Romanovsky wrote:
> >
> > The autoselection process works good enough for everything outside
> > of netdev community.
>
> That's very far from true. I have seen and heard many complaints about
> AUTOSEL and inflation of stable trees in general, both in private and in
> public lists. It was also discussed on Kernel Summit few times - with
> little success.

I'm aware of the discussions and the cases brought there. From what I
saw, Sasha and Greg came with numbers and process that is much better
than anything else we had before. While the opponents came with very
narrow examples of imperfections in AUTOSEL machinery.

Of course, the AUTOSEL mechanism is not perfect and prone to errors,
but it is much better than try to rely on the developers good will to
add Fixes and stable@ tag.

It is pretty easy to be biased while receiving those complaints, because
people are contacting us only if something is broken. I imagine that no one
is approaching you and expressing his happiness with stable@ or anything
else.

Just for fun and to get perspective, for one my very popular tool, which
I wrote two years ago, I received only ONE "thank you" email that says that
this tool works as expected and helped to identify the problem.

And personally, I'm running latest Fedora on all my servers and laptop and
it works great - stable and reliable.

Thanks

>
> Just for fun, I suggest everyone to read first section of
> Documentation/process/stable-kernel-rules.rst and compare with today's
> reality. Of course, rules can change over time but keeping that document
> in kernel tree as a memento is rather sad - I went through the rules now
> and there are only three which are not broken on a regular basis these
> days.
>
> Michal Kubecek