On 1/1/20 8:24 AM, Greg Kroah-Hartman wrote:
On Tue, Dec 31, 2019 at 06:01:12PM -0800, Guenter Roeck wrote:
On 12/30/19 9:35 AM, Greg Kroah-Hartman wrote:
On Mon, Dec 30, 2019 at 09:19:59AM -0800, Guenter Roeck wrote:
On Sun, Dec 29, 2019 at 06:16:42PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.92 release.
There are 219 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue, 31 Dec 2019 16:17:25 +0000.
Anything received after that time might be too late.
Build results:
total: 156 pass: 141 fail: 15
Failed builds:
i386:tools/perf
<all mips>
x86_64:tools/perf
Qemu test results:
total: 381 pass: 316 fail: 65
Failed tests:
<all mips>
<all ppc64_book3s_defconfig>
perf as with v4.14.y.
arch/mips/kernel/syscall.c:40:10: fatal error: asm/sync.h: No such file or directory
Ah, will go drop the offending patch and push out a -rc2 with both of
these issues fixed.
arch/powerpc/include/asm/spinlock.h:56:1: error: type defaults to ‘int’ in declaration of ‘DECLARE_STATIC_KEY_FALSE’
and similar errors.
The powerpc build problem is inherited from mainline and has not been fixed
there as far as I can see. I guess that makes 4.19.y bug-for-bug "compatible"
with mainline in that regard.
bug compatible is fun :(
Not really. It is a terrible idea and results in the opposite of what I would
call a "stable" release.
Anyway, turns out the offending commit is 14c73bd344d ("powerpc/vcpu: Assume
dedicated processors as non-preempt"), which uses static_branch_unlikely().
It does? I see:
+ if (lppaca_shared_proc(get_lppaca()))
+ static_branch_enable(&shared_processor);
This function does not exist for ppc in v4.19.y and v5.4.y. Thus, the _impact_
of the error in v4.19.y and v5.4.y is the same as in mainline, but the _cause_
is different. Upstream commit 14c73bd344d should not have been applied to
v4.19.y and v5.4.y and needs to be reverted from those branches.
I'll go revert this patch, but as it was marked for stable by the
authors of the patch, as relevant back to 4.18, I would have hoped that
they knew what they were doing :)
I probably didn't have enough champagne last night when I wrote my previous e-mail.
No, the problem is the same as with the upstream kernel, so feel free to drop
the revert if you prefer "bug-for-bug compatibility". Given where we are, that
is probably better than dropping the patch and re-applying it after its fix
is available.
The underlying problem is that the offending patch introduces the use of
jump label code into arch/powerpc/include/asm/spinlock.h without including
linux/jump_label.h. Depending on the configuration, this results in the observed
build errors.
Patches were submitted upstream to fix the problem, but the fix has not been
applied to mainline, and I don't see a maintainer reaction. Maybe everyone
is off for the holidays.
https://patchwork.ozlabs.org/patch/1215380/
https://patchwork.ozlabs.org/patch/1214954/
Guenter
