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: <20200414205755.GF1068@sasha-vm>
Date:   Tue, 14 Apr 2020 16:57:55 -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 Tue, Apr 14, 2020 at 04:49:20PM +0100, Edward Cree wrote:
>On 14/04/2020 16:16, Sasha Levin wrote:
>> Are you suggesting that a commit without a fixes tag is never a fix?
>Because fixes are much more likely than non-fixes to have a Fixes tag,
> the absence of a fixes tag is Bayesian evidence that a commit is not
> a fix.  It's of course not incontrovertible evidence, since (as you
> note) some fixes do not have a Fixes tag, but it does increase the
> amount of countervailing evidence needed to conclude a commit is a fix.
>In this case it looks as if the only such evidence was that the commit
> message included the phrase "NULL pointer dereference".

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?

$ git log --oneline -i --grep "fixes:" v4.19..stable/linux-4.19.y | wc -l
6235
$ git log --oneline v4.19..stable/linux-4.19.y | wc -l
12877

Look at that, most fixes in -stable *don't* have a fixes tag. Shouldn't
your argument be the opposite? If a patch has a fixes tag, it's probably
not a fix?

"it does increase the amount of countervailing evidence needed to
conclude a commit is a fix" - Please explain this argument given the
above.

>> Fixes can (and should) come in during a merge window as well. They are
>> not put on hold until the -rc releases.
>In networking-land, fixes generally go through David's 'net' tree, rather
> than 'net-next'; the only times a fix goes to net-next are when

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.

>a) the code it's fixing is only in net-next; i.e. it's a fix to a previous
> patch from the same merge window.  In this case the fix should not be
> backported, since the code it's fixing will not appear in stable kernels.
>b) the code has changed enough between net and net-next that different
> fixes are appropriate for the two trees.  In this case, only the fix that
> went to 'net' should be backported (since it's the one that's appropriate
> for net, it's probably more appropriate for stable trees too); the fix
> that went to 'net-next' should not.
>Or's original phrasing was that this patch "was pushed to net-next", which
> is not quite exactly the same thing as -next vs. -rc (though it's similar
> because of David's system of closing net-next for the duration of the
> merge window).  And this, again, is quite strong Bayesian evidence that
> the patch should not be selected for stable.
>
>To be honest, that this needs to be explained to you does not inspire
> confidence in the quality of your autoselection process...

Nothing like a personal attack or two to try and make a point?

-- 
Thanks,
Sasha