Date:   Thu, 16 Apr 2020 17:17:09 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Edward Cree <ecree@...arflare.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        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 Thu, Apr 16, 2020 at 5:04 PM Sasha Levin <sashal@...nel.org> wrote:
> On Thu, Apr 16, 2020 at 04:40:31PM +0300, Or Gerlitz wrote:
> >On Thu, Apr 16, 2020 at 3:00 AM Sasha Levin <sashal@...nel.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.
>
> Sure, here are 5 from the past few months:
>
> e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor")
> 3d94a4a8373b ("mwifiex: fix possible heap overflow in mwifiex_process_country_ie()")
> 39d170b3cb62 ("ath6kl: fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe()")
> 8b51dc729147 ("rsi: fix a double free bug in rsi_91x_deinit()")
> 5146f95df782 ("USB: hso: Fix OOB memory access in hso_probe/hso_get_config_data")
>
> 5 Different drivers, neither has a stable tag or a Fixes: tag, all 5
> have a CVE number assigned to them.

CVE number sounds good enough to me to AI around and pull to
stable,  BUT only to where relevant, and nothing beyond (see below).

> >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.
>
> Thanks for doing it - we do see more and more fixes tags.
>
> >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.
>
> Humans are still humans, and humans make mistakes. Fixes tags get
> forgotten

In the netdev land, the very much usual habit is for -rc patches to have
Fixes tag, so maybe some RCA comment here would be to
enforce that better across the kermel land?

> stable tags get forgotten.

An easy AI would be to deduce the -stable tag from the -fixes tag, just
find out where the offending patch was accepted and never/ever (please!)
push a fix beyond that kernel.

> I very much belive you that the mellanox stuff are in good shape thanks
> to your efforts, but the kernel world is bigger than a few select drivers.

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

> See above (the example commits). The drivers/net/ stuff don't work as
> well as net/ sadly.

Disagree.

If there is a problem it is due to some driver/net/ driver maintainers
not doing their job good enough.

> >> 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.
>
> How come? DaveM is specifically asking not to add stable tags because he
> will do the selection himself, right? So the hyperv stuff indeed don't
> include a stable tag, but all fixes should have a proper Fixes: tag.

Ask/tell your maintainer to note that in their cover letters, it will be taken.

> So why don't they end up in a stable tree?

> If we need to send a mail saying which commits should go to stable, we
> might as well tag them for stable to begin with, right?

so how about you go and argue with the netdev maintainer and
settle your complaints instead of WA your disagreements using autosel?

Powered by blists - more mailing lists