All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Usama Arif <usama.arif@bytedance.com>
Cc: dwmw2@infradead.org, tglx@linutronix.de, kim.phillips@amd.com,
	brgerst@gmail.com, piotrgorski@cachyos.org,
	oleksandr@natalenko.name, arjan@linux.intel.com,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, x86@kernel.org, pbonzini@redhat.com,
	paulmck@kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, rcu@vger.kernel.org, mimoja@mimoja.de,
	hewenliang4@huawei.com, thomas.lendacky@amd.com,
	seanjc@google.com, pmenzel@molgen.mpg.de,
	fam.zheng@bytedance.com, punit.agrawal@bytedance.com,
	simon.evans@bytedance.com, liangma@liangbit.com,
	gpiccoli@igalia.com, David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PATCH v16 2/8] cpu/hotplug: Reset task stack state in _cpu_up()
Date: Wed, 22 Mar 2023 11:06:16 +0000	[thread overview]
Message-ID: <ZBrhKERLxvklAhiP@FVFF77S0Q05N> (raw)
In-Reply-To: <20230321194008.785922-3-usama.arif@bytedance.com>

On Tue, Mar 21, 2023 at 07:40:02PM +0000, Usama Arif wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Commit dce1ca0525bf ("sched/scs: Reset task stack state in bringup_cpu()")
> ensured that the shadow call stack and KASAN poisoning were removed from
> a CPU's stack each time that CPU is brought up, not just once.
> 
> This is not incorrect. However, with parallel bringup, an architecture
> may obtain the idle thread for a new CPU from a pre-bringup stage, by
> calling idle_thread_get() for itself. This would mean that the cleanup
> in bringup_cpu() would be too late.
> 
> Move the SCS/KASAN cleanup to the generic _cpu_up() function instead,
> which already ensures that the new CPU's stack is available, purely to
> allow for early failure. This occurs when the CPU to be brought up is
> in the CPUHP_OFFLINE state, which should correctly do the cleanup any
> time the CPU has been taken down to the point where such is needed.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

This all sounds fine to me, and the patch itself looks good.

I built an arm64 kernel with the first three patches from this series applied
atop v6.3-rc3, with defconfig + CONFIG_SHADOW_CALL_STACK=y +
CONFIG_KASAN_INLINE=y + CONFIG_KASAN_STACK=y. I then hotplugged a cpu with:

  while true; do
    echo 0 > /sys/devices/system/cpu/cpu1/online;
    echo 1 > /sys/devices/system/cpu/cpu1/online;
  done

... and that was perfectly happy to run for minutes with no unexpected failures.

To make sure I wasn't avoiding issues by chance, I also tried with each of
scs_task_reset() and kasan_unpoison_task_stack() commented out. With
scs_task_reset() commented out, cpu re-onlining fails after a few iterations,
and with kasan_unpoison_task_stack() commented out I get a KASAN splat upon the
first re-onlining. So that all looks good.

FWIW, for the first three patches:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [arm64]

Mark.

> ---
>  kernel/cpu.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 6c0a92ca6bb5..43e0a77f21e8 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -591,12 +591,6 @@ static int bringup_cpu(unsigned int cpu)
>  	struct task_struct *idle = idle_thread_get(cpu);
>  	int ret;
>  
> -	/*
> -	 * Reset stale stack state from the last time this CPU was online.
> -	 */
> -	scs_task_reset(idle);
> -	kasan_unpoison_task_stack(idle);
> -
>  	/*
>  	 * Some architectures have to walk the irq descriptors to
>  	 * setup the vector space for the cpu which comes online.
> @@ -1383,6 +1377,12 @@ static int _cpu_up(unsigned int cpu, int tasks_frozen, enum cpuhp_state target)
>  			ret = PTR_ERR(idle);
>  			goto out;
>  		}
> +
> +		/*
> +		 * Reset stale stack state from the last time this CPU was online.
> +		 */
> +		scs_task_reset(idle);
> +		kasan_unpoison_task_stack(idle);
>  	}
>  
>  	cpuhp_tasks_frozen = tasks_frozen;
> -- 
> 2.25.1
> 

  reply	other threads:[~2023-03-22 11:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 19:40 [PATCH v16 0/8] Parallel CPU bringup for x86_64 Usama Arif
2023-03-21 19:40 ` [PATCH v16 1/8] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> Usama Arif
2023-03-21 19:40 ` [PATCH v16 2/8] cpu/hotplug: Reset task stack state in _cpu_up() Usama Arif
2023-03-22 11:06   ` Mark Rutland [this message]
2023-03-21 19:40 ` [PATCH v16 3/8] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU Usama Arif
2023-03-23 22:36   ` Thomas Gleixner
2023-03-23 22:49     ` David Woodhouse
2023-03-23 23:48       ` Thomas Gleixner
2023-03-24  0:06         ` David Woodhouse
2023-03-23 23:05     ` Thomas Gleixner
2023-03-23 23:12       ` David Woodhouse
2023-03-24  1:16         ` Thomas Gleixner
2023-03-24  9:31           ` David Woodhouse
2023-03-24 13:57             ` Thomas Gleixner
2023-03-24 15:33               ` David Woodhouse
2023-03-24 14:07             ` Thomas Gleixner
2023-03-24  9:46           ` Thomas Gleixner
2023-03-24 10:00             ` David Woodhouse
2023-03-27 18:48       ` David Woodhouse
2023-03-21 19:40 ` [PATCH v16 4/8] x86/smpboot: Split up native_cpu_up into separate phases and document them Usama Arif
2023-03-21 19:40 ` [PATCH v16 5/8] x86/smpboot: Support parallel startup of secondary CPUs Usama Arif
2023-03-21 19:40 ` [PATCH v16 6/8] x86/smpboot: Send INIT/SIPI/SIPI to secondary CPUs in parallel Usama Arif
2023-03-21 19:40 ` [PATCH v16 7/8] x86/smpboot: Serialize topology updates for secondary bringup Usama Arif
2023-03-21 19:40 ` [PATCH v16 8/8] x86/smpboot: Allow parallel bringup for SEV-ES Usama Arif
2023-03-22 22:47   ` Borislav Petkov
2023-03-23  8:32     ` David Woodhouse
2023-03-23  8:51       ` Borislav Petkov
2023-03-23  9:04         ` David Woodhouse
2023-03-23 14:23           ` Brian Gerst
2023-03-27 17:47             ` Borislav Petkov
2023-03-27 18:14               ` David Woodhouse
2023-03-27 19:14                 ` Tom Lendacky
2023-03-27 19:32                 ` Borislav Petkov
2023-03-23 13:16     ` Tom Lendacky
     [not found]       ` <751f572f940220775054dc09324b20b929d7d66d.camel@amazon.co.uk>
2023-03-23 18:28         ` Tom Lendacky
2023-03-23 22:13           ` Borislav Petkov
2023-03-23 22:30             ` [EXTERNAL][PATCH " David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZBrhKERLxvklAhiP@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=dwmw@amazon.co.uk \
    --cc=fam.zheng@bytedance.com \
    --cc=gpiccoli@igalia.com \
    --cc=hewenliang4@huawei.com \
    --cc=hpa@zytor.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=liangma@liangbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mimoja@mimoja.de \
    --cc=mingo@redhat.com \
    --cc=oleksandr@natalenko.name \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=piotrgorski@cachyos.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=punit.agrawal@bytedance.com \
    --cc=rcu@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=simon.evans@bytedance.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=usama.arif@bytedance.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.