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:   Tue, 14 Apr 2020 16:49:20 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Or Gerlitz <gerlitz.or@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>
CC:     Sasha Levin <sashal@...nel.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 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".

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

GregKH wrote:
> we can't get make this a "only take if I agree" as there are _many_
> subsystem maintainers who today never mark anything for stable trees
The complaint seems to be that Sasha's threshold for "this looks stable-
 worthy" is too low; maybe setting it that low should be opt-in, while
 patches for subsystems that haven't opted in should need to be
 "obviously" fixes for them to get autoselected, on the grounds that
 having to watch the autosel messages and pounce on the ones to which
 the answer is "no no no, applying that to stable kernels will break
 them horribly" is _also_ extra work for a maintainer.  (Especially if,
 a month after NACKing them, the same patch shows up again in another
 autosel batch, which — unless my memory is playing tricks on me — has
 happened to me at least once.)

-ed