On Wed, Apr 22, 2020 at 10:53:33AM +0200, Vegard Nossum wrote:
On 4/22/20 10:34 AM, Greg KH wrote:
On Wed, Apr 22, 2020 at 10:21:23AM +0200, Vegard Nossum wrote:
Hi,
There is no point in taking this patch on any stable kernel as it's just
improving a build error diagnostic message.
build error messages are nice to have be correct, don't you think?
Seems like a valid fix for me.
thanks,
greg k-h
The patch will break on gcc 4.2 and earlier, so if the older stable
kernels support those then people might be surprised. The mainline patch
was deemed fine since gcc 4.6 is required. More info here:
<https://lkml.org/lkml/2020/3/31/1477>
If no stable kernel is built with gcc <= 4.2 then you can disregard this.
I think the patch also doesn't really satisfy the following criteria
from stable_kernel_rules.txt:
- "It must fix a real bug that bothers people": It bothered me (and I
ran into the bug) on mainline, but that was while writing brand new code
that used BUILD_BUG_ON(). Presumably these things will not fire on
existing kernel code.
- "It must fix a problem that causes a build error ...": It doesn't fix
any of the things listed, not even a build error, just a _diagnostic_
for an incredibly rare case of a rare kind of build error.
In the end, I am not personally opposed to having the patch in stable,
but it seems to go against everything I've ever heard about stable rules
so I'm a bit surprised when you take it anyway. I think it might reduce
people's trust in stable kernels if any random weird patch is taken
uncritically when even the patch author points out that it doesn't fit
the criteria!
Hey Vegard,
I'll drop it.
In general, patches that address build issues are easier to rationalize
in the context of stable as the regressions they might cause will be
limited to build time.
--
Thanks,
Sasha
