Subject: Re: [PATCH] Work around for enabling CONFIG_CMDLINE on ppc64le

From: Akshay Adiga <[email-masked]>
Date: Tue, 27 Sep 2016 23:24:34 +0530

Hi Michael,

Here is the link to the bug raised on launchpad.
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1628207

On 09/23/2016 09:45 AM, Akshay Adiga wrote:
> Hi Michael,
>
> Anton found this bug and raised it against gcc v7.0 and a fix is 
> available
>  in upstream gcc.
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
>
> Currently, gcc v5.4.0  and v6.1.1 shipped with Ubuntu 16.04 and 16.10  
> respectively,
>  are hitting this problem.
>
> I have also raised bug against Ubuntu for fixing gcc for 16.04.
>
> https://bugzilla.linux.ibm.com/show_bug.cgi?id=146668
>
>
> On 09/22/2016 03:51 PM, Michael Ellerman wrote:
>> Akshay Adiga <[email-masked]> writes:
>>
>>> Observed that boot arguments (passed as CONFIG_CMDLINE)  are not being
>>> picked up by kernel while using gcc-ppc64-linux-gnu v5.4.0 and v6.1.1.
>>> While it works as expected with v5.3.1 .
>>>
>>> Found that in init/main.c in  setup_command_line() the pointers 
>>> passed to
>>> strcpy() is messed up.
>> Hi Akshay,
>>
>> Thanks for debugging this.
>>
>>> The problem goes away when compiler optimization is restricted to -O1.
>>> diff --git a/init/main.c b/init/main.c
>>> index a8a58e2..4259c42 100644
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -358,7 +358,13 @@ static inline void smp_prepare_cpus(unsigned 
>>> int maxcpus) { }
>>>    * parsing is performed in place, and we should allow a component to
>>>    * store reference of name/value for future reference.
>>>    */
>>> -static void __init setup_command_line(char *command_line)
>>> +static void __init
>>> +#ifdef CONFIG_PPC64
>>> +    #if  GCC_VERSION > 50301
>>> +        __attribute__((optimize("-O1")))
>>> +    #endif
>>> +#endif
>>> +        setup_command_line(char *command_line)
>>>   {
>>>       saved_command_line =
>>>           memblock_virt_alloc(strlen(boot_command_line) + 1, 0);
>> But I can't merge that patch.
>>
>> Our options are one or both of:
>>   - get GCC fixed and backport the fix to the compilers we care about.
>>   - blacklist the broken compiler versions.
>>
>> Is there a GCC bug filed for this?
>>
>> cheers
>>
>