[PATCH] arm64: smp: Add a memory barrier before we start secondary cores
Will Deacon
will.deacon at arm.com
Wed Feb 12 07:27:28 EST 2014
On Wed, Feb 12, 2014 at 11:46:34AM +0000, Mark Brown wrote:
> From: Mark Brown <broonie at linaro.org>
>
> Ensure that memory writes will be visible to the newly started core by
> inserting a write barrier prior to starting. This adds robustness against
> possible incomplete synchronisation of state.
This is very vague. I still don't understand what this is being used for.
> Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Mark Brown <broonie at linaro.org>
> ---
> arch/arm64/kernel/smp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 9660750f34ba..f5520d8fafab 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -160,6 +160,11 @@ asmlinkage void secondary_start_kernel(void)
> smp_store_cpu_info(cpu);
>
> /*
> + * Ensure memory writes are visible before we start.
> + */
> + smp_wmb();
> +
> + /*
> * OK, now it's safe to let the boot CPU continue. Wait for
> * the CPU migration code to notice that the CPU is online
> * before we continue.
So right after this comment we complete(&cpu_running), which implies a write
barrier if we wake somebody up. The secondary coming up should be waiting on
that completion, so *that* is how synchronisation is achieved.
Without a concrete example of precisely why this is required, I'm not at all
happy taking patches adding random memory barriers.
Will
More information about the linux-arm-kernel
mailing list