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 :)
thanks,
greg k-h
