Re: [RFC PATCH] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up

[Michal Simek]

On 31. 07. 19 6:12, Luis Araneda wrote:
> Hi Russell,
> 
> Thanks for reviewing.
> 
> On Tue, Jul 30, 2019 at 6:47 AM Russell King - ARM Linux admin
> <linux@xxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, Jul 30, 2019 at 12:43:26AM -0400, Luis Araneda wrote:
>>> This fixes a kernel panic (read overflow) on memcpy when
>>> FORTIFY_SOURCE is enabled.
> [...]
>>
>> I'm not convinced that this is correct.  It looks like
>> zynq_secondary_trampoline could be either ARM or Thumb code - there is
>> no .arm directive before it.  If it's ARM code, then this is fine.  If
>> Thumb code, then zynq_secondary_trampoline will be offset by one, and
>> we will miss copying the first byte of code.
> 
> You're right, I tested what happens if the zynq_secondary_trampoline
> is ARM or Thumb by editing the file where it's defined, headsmp.S
> 
> When the .arm directive is used, the CPU is brought-up correctly,
> but if I use .thumb, I get the following message (no panic):
>> CPU1: failed to come online
> 
> This seems unrelated to solving the panic, as the message
> even appears with memcpy and FORTIFY_SOURCE disabled.
> 
> I could add the .arm directive to headsmp.S
> Is that your expected solution?
> Should that change be on a separate commit?
> 
> I'd like to know Michal's opinion, as he wrote the code.
> 

There are two things together. Thanks Russel to pointing to it.
1. How to support SMP in thumb2 mode?
Adding .arm mode to headsmp.S which ensure that cpu starts in proper
mode and correct code size is copied.
And also point to secondary_startup_arm in zynq_boot_secondary to switch
cpu from arm to thumb mode.

2. And the second is this patch to fix FORTIFY_SOURCE.

Feel free to create the first patch too or I will do it myself.

Thanks,
Michal