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]

Date:   Wed, 15 Apr 2020 20:00:09 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Or Gerlitz <gerlitz.or@...il.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 Wed, Apr 15, 2020 at 05:18:38PM +0100, Edward Cree wrote:
>Firstly, let me apologise: my previous email was too harsh and too
> assertiveabout things that were really more uncertain and unclear.
>
>On 14/04/2020 21:57, Sasha Levin wrote:
>> I've pointed out that almost 50% of commits tagged for stable do not
>> have a fixes tag, and yet they are fixes. You really deduce things based
>> on coin flip probability?
>Yes, but far less than 50% of commits *not* tagged for stable have a fixes
> tag.  It's not about hard-and-fast Aristotelian "deductions", like "this
> doesn't have Fixes:, therefore it is not a stable candidate", it's about
> probabilistic "induction".
>
>> "it does increase the amount of countervailing evidence needed to
>> conclude a commit is a fix" - Please explain this argument given the
>> above.
>Are you familiar with Bayesian statistics?  If not, I'd suggest reading
> something like http://yudkowsky.net/rational/bayes/ which explains it.
>There's a big difference between a coin flip and a _correlated_ coin flip.

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

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

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 really have no objection to not looking in drivers/net/, it's just
that the experience I had with the process suggests that it's not
following the same process as net/.

-- 
Thanks,
Sasha