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: <20200415140723.GH1068@sasha-vm>
Date:   Wed, 15 Apr 2020 10:07:23 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org, Leon Romanovsky <leon@...nel.org>,
        Edward Cree <ecree@...arflare.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Stable <stable@...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 Wed, Apr 15, 2020 at 12:50:09AM +0200, Michal Kubecek wrote:
>On Tue, Apr 14, 2020 at 08:37:18PM +0300, Leon Romanovsky wrote:
>>
>> The autoselection process works good enough for everything outside
>> of netdev community.
>
>That's very far from true. I have seen and heard many complaints about

How about some actionable data? What do you expect us to do with "seen
and heard"?

Do you have evidence that AUTOSEL introduces more regressions over the
stable tagged commits? Do you have evidence showing that AUTOSEL isn't
performing properly? Great, let's go over it.

I have always measured the results of this work and compared it to the
"regular" flow of stable tagged commits, I'm keeping track of how the
quality of it compares to those stable tagged commits, and quite a few
times I took action to deal with specific issues that come up with the
process based on data.

There's not much I can do with "seen and heard".

>AUTOSEL and inflation of stable trees in general, both in private and in

I'm puzzled about your objections to "inflation"? The stable tree was
missing a bunch of fixes before, and now it doesn't.

In parallel to "inflating" the stable trees I'm also driving efforts to
improve the testing of these trees so that we could reliably say that we
didn't introduce any regressions into the stable tree. "inflation" on
it's own doesn't increase the rate of regressions in stable trees, and
that's based on historical data.

>public lists. It was also discussed on Kernel Summit few times - with
>little success.

Define success? We're adding a bunch of missing fixes and not causing
any more regressions than before, you don't call that a success?

Let me also point out that I've tried to bring up this process (as well
as the -stable process in general) at every kernel summit/maintainer's
summit (here's the one from last year: https://lwn.net/Articles/799166/)
and attempted to address any feedback that came back from it. It seemed
to me that there's an agreement that this process was going well (at the
very least Linus didn't yell at me), so I'm still puzzled by your own
success criteria.

-- 
Thanks,
Sasha