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: <20200414071622.GT334007@unreal>
Date:   Tue, 14 Apr 2020 10:16:22 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Or Gerlitz <gerlitz.or@...il.com>,
        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 Mon, Apr 13, 2020 at 09:56:28PM -0400, Sasha Levin 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?

Saeed asks from Dave explicitly to pick commits to stable@.
https://lore.kernel.org/netdev/20200408225124.883292-1-saeedm@mellanox.com/

>
> > > 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.

I was under impression that all netdev commits are excluded.

Thanks

>
> --
> Thanks,
> Sasha