On 2 January 2020 4:28:29 am AEDT, Guenter Roeck linux@roeck-us.net wrote:
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.
I am off for the "holidays". But I put the patch in my fixes branch a few days ago, I'll send a pull to Linus tomorrow.
cheers