[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