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: <CAJ3xEMiS59mHtAhhejXNEknzq89841TWycZaiq=Q_50p-BqFpg@mail.gmail.com>
Date:   Sun, 12 Apr 2020 21:29:10 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeedm@...lanox.com>
Cc:     Sasha Levin <sashal@...nel.org>, Stable <stable@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

On Sun, Apr 12, 2020 at 8:59 PM Jakub Kicinski <kuba@...nel.org> 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
> > to go and pick that into stable and from there to customer production kernels.
> >
> > 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
> > 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?

+1