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