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]

Date:   Tue, 14 Apr 2020 13:22:59 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     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 4:56 AM Sasha Levin <sashal@...nel.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@...nel.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?