Message-ID: <20200416140441.GL1068@sasha-vm>
Date:   Thu, 16 Apr 2020 10:04:41 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Or Gerlitz <gerlitz.or@...il.com>
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 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.

>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, stable tags get forgotten.

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.

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

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?

>[1] actually I do remember that once or twice out of the 2020 times we asked,  a
>patch was not sent to -stable by the sub-system maintainer mistake
>which he fixed(..) later

-- 
Thanks,
Sasha

Powered by blists - more mailing lists