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: 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: Tue, 14 Apr 2020 13:22:59 +0300	[thread overview]
Message-ID: <CAJ3xEMh=PGVSddBWOX7U6uAuazJLFkCpWQNxhg7dDRgnSdQ=xA@mail.gmail.com> (raw)
In-Reply-To: <20200414015627.GA1068@sasha-vm>

On Tue, Apr 14, 2020 at 4:56 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Sun, Apr 12, 2020 at 10:59:35AM -0700, Jakub Kicinski wrote:
> >On Sun, 12 Apr 2020 10:10:22 +0300 Or Gerlitz wrote:
> >> On Sun, Apr 12, 2020 at 2:16 AM Sasha Levin <sashal@kernel.org> wrote:
> >>
> >> > [ Upstream commit 6783e8b29f636383af293a55336f036bc7ad5619 ]
> >>
> >> Sasha,
> >>
> >> This was pushed to net-next without a fixes tag, and there're probably
> >> reasons for that.
> >> As you can see the possible null deref is not even reproducible without another
> >> patch which for itself was also net-next and not net one.
> >>
> >> If a team is not pushing patch to net nor putting a fixes that, I
> >> don't think it's correct
>
> While it's great that you're putting the effort into adding a fixes tag
> to your commits, I'm not sure what a fixes tag has to do with inclusion
> in a stable tree.
>
> It's a great help when we look into queueing something up, but on it's
> own it doesn't imply anything.
>
> >> to go and pick that into stable and from there to customer production kernels.
>
> This mail is your two week warning that this patch might get queued to
> stable, nothing was actually queued just yet.
>
> >> Alsom, I am not sure what's the idea behind the auto-selection concept, e.g for
> >> mlx5 the maintainer is specifically pointing which patches should go
> >> to stable and
>
> I'm curious, how does this process work? Is it on a mailing list
> somewhere?
>
> >> to what releases there and this is done with care and thinking ahead, why do we
> >> want to add on that? and why this can be something which is just
> >> automatic selection?
> >>
> >> We have customers running production system with LTS 4.4.x and 4.9.y (along with
> >> 4.14.z and 4.19.w) kernels, we put lots of care thinking if/what
> >> should go there, I don't
> >> see a benefit from adding auto-selection, the converse.
> >
> >FWIW I had the same thoughts about the nfp driver, and I indicated to
> >Sasha to skip it in the auto selection, which AFAICT worked nicely.
> >
> >Maybe we should communicate more clearly that maintainers who carefully
> >select patches for stable should opt out of auto-selection?
>
> I've added drivers/net/ethernet/mellanox/ to my blacklist for auto
> selection. It's very easy to opt out, just ask... I've never argued with
> anyone around this - the maintainers of any given subsystem know about
> it way better than me.

Just to make sure, does this excluding of mlx5 happens immediately, that is,
applies also to all non committed patches that you already posted?

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?