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

From: Or Gerlitz <gerlitz.or@gmail.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Edward Cree <ecree@solarflare.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Jakub Kicinski <kuba@kernel.org>, Stable <stable@vger.kernel.org>,
	Linux Netdev List <netdev@vger.kernel.org>,
	Saeed Mahameed <saeedm@mellanox.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors
Date: Thu, 16 Apr 2020 16:40:31 +0300	[thread overview]
Message-ID: <CAJ3xEMjfWL=c=voGqV4pUCzWXmiTn-R6mrRi82UAVHMVysKU1g@mail.gmail.com> (raw)
In-Reply-To: <20200416000009.GL1068@sasha-vm>

On Thu, Apr 16, 2020 at 3:00 AM Sasha Levin <sashal@kernel.org> wrote:
> I'd maybe point out that the selection process is based on a neural
> network which knows about the existence of a Fixes tag in a commit.
>
> It does exactly what you're describing, but also taking a bunch more
> factors into it's desicion process ("panic"? "oops"? "overflow"? etc).

As Saeed commented, every extra line in stable / production kernel
is wrong. IMHO it doesn't make any sense to take into stable automatically
any patch that doesn't have fixes line. Do you have 1/2/3/4/5 concrete
examples from your (referring to your Microsoft employee hat comment
below) or other's people production environment where patches proved to
be necessary but they lacked the fixes tag - would love to see them.

We've been coaching new comers for years during internal and on-list
code reviews to put proper fixes tag. This serves (A) for the upstream
human review of the patch and (B) reasonable human stable considerations.

You are practically saying that for cases we screwed up stage (A) you
can somehow still get away with good results on stage (B) - I don't
accept it. BTW - during my reviews I tend to ask/require developers to
skip the word panic, and instead better explain the nature of the
problem / result.

>>> This is great, but the kernel is more than just net/. Note that I also
>>> do not look at net/ itself, but rather drivers/net/ as those end up with
>>> a bunch of missed fixes.

>>drivers/net/ goes through the same DaveM net/net-next trees, with the
>> same rules.

you ignored this comment, any more specific complaints?

> Let me put my Microsoft employee hat on here. We have driver/net/hyperv/
> which definitely wasn't getting all the fixes it should have been
> getting without AUTOSEL.

> While net/ is doing great, drivers/net/ is not. If it's indeed following
> the same rules then we need to talk about how we get done right.

I never [1] saw -stable push requests being ignored here in netdev.
Your drivers have four listed maintainers and it's common habit by
commercial companies to have paid && human (non autosel robots)
maintainers that take care of their open source drivers. As in commercial
SW products, Linux has a current, next and past (stable) releases, so
something sounds as missing to me in your care matrix.

[1] actually I do remember that once or twice out of the 2020 times we asked,  a
patch was not sent to -stable by the sub-system maintainer mistake
which he fixed(..) later