Re: [PATCH 4.19 000/219] 4.19.92-stable review

[Michael Ellerman]

On 2 January 2020 4:28:29 am AEDT, Guenter Roeck <linux@xxxxxxxxxxxx> 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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.