Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp969051rwr; Thu, 4 May 2023 12:06:40 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5QH6fG5L9K1DHoKaYy8o3ZwqahT0gcay1vnXqhJK+YBPaKTmLuimtkMJpFl85PYKTUkxNi X-Received: by 2002:a17:90b:2251:b0:23c:ffbf:859e with SMTP id hk17-20020a17090b225100b0023cffbf859emr3021866pjb.35.1683227200504; Thu, 04 May 2023 12:06:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683227200; cv=none; d=google.com; s=arc-20160816; b=XN3rEoINwpim5X5PjzjIDYgqtZqXUOBorxZSMMskMlqaoT1mBYKy7cr3dqn1YaQkCq YJauldMeUqLLTIbAUPAmAAQCqLr2r6QlRcGXbba868fn1wJtbgeWcypt7nBqRPuxQqnp 2Y//Bj9dfCb6S20g/j7Q335A5cVVvTUy+kkjTT1GxVuYqdLGoNstBukmCkOuo5scy7TW HCkuXBJ7M8iikUNUnRDtA61FQ1wpzZ1Go0VnfrakGqAfz2jii6yZ4HdLwNb7DXmHQq97 LTO5ux31i8abemTflq2Ojn9WkgfFb2pxCwFLP1gHNwaCq3GHMruhWeT26C3g0EIMcaNY FkOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:mime-version:references:subject:cc:to:from :dkim-signature:dkim-signature:message-id; bh=x1gYrMcqzm40p2bz6RsOmSrXlBcSvXXbnfB8HNeCbJU=; b=cM4RNmR+9K3k2PrGzvYQJ8X5QNcj+qjKyMhZ8SruEnrLM4jxcDY0crjQGI4OeJo3qJ nHbvsiA/Fmfhf7iNRWnBjZQ3Kd9Gf0ZMA32jZVgLM5XUcQFaq0kcAq43HeTjJuxP5Np3 bb3Y6m9ZjSoNi5Wg9QAiIkdPydGIVwviJt+sdDArQzd+x39obMCGXSnXtffbKXUa+ZGi hlppGbW9+lt+tVdybWo8bn52Co+wxFJv9Zj7pGlxcMdH73McBGPdhEOtKqGyATgs5J7A D8WkpeLELhZQeY/HCKVIAxvziCYfuNlS4aPjXJ5W18HDn9HnbHbKQ12JPyWKfWyB7gg1 +odg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=F9VwenKV; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fw20-20020a17090b129400b0024e500f3749si3895537pjb.68.2023.05.04.12.06.25; Thu, 04 May 2023 12:06:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=F9VwenKV; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230349AbjEDTEU (ORCPT + 99 others); Thu, 4 May 2023 15:04:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230148AbjEDTDh (ORCPT ); Thu, 4 May 2023 15:03:37 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FFDB7A97; Thu, 4 May 2023 12:02:50 -0700 (PDT) Message-ID: <20230504185937.858955768@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1683226964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=x1gYrMcqzm40p2bz6RsOmSrXlBcSvXXbnfB8HNeCbJU=; b=F9VwenKVSYd9QFli8bXNV/fz9qUSdzJcPELJ1ngRD9BxyzaHEgcu2cC0/b4kuprOfTMBsR NCkyPWtTcKTi4mTU6aAeMY6PYflFdg/QnWMligdTnr5DQ53G/59w7N1RxTuaJMuxKaB+6k fnxGx7t6MsQx4TP0A/Wv1B3YJqsjI01JirGXHQPo53zTdX5Z488sLyftTciloBgiN9k5k/ bzf3t4Qwlj6lxCy0qHukKPQMZGDuh3h1yP7MJWtYXWHVZt3htrK/Qtw9ul4ERCfXuX9Nze it6Ui4ad23Dml/cuVbhr6i6cHXzKyVbR3juE2BxVW820qfkeEJiZvG833WVS3g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1683226964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=x1gYrMcqzm40p2bz6RsOmSrXlBcSvXXbnfB8HNeCbJU=; b=PK3VhwCrlpzYLlITMOVdXxhPHsDqoA73a6Tz+/QOqHPRfKtGaiwEqnA7EtTcL4VMvMoxp6 ebRWKW/d8KnEHmAA== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, David Woodhouse , Andrew Cooper , Brian Gerst , Arjan van de Veen , Paolo Bonzini , Paul McKenney , Tom Lendacky , Sean Christopherson , Oleksandr Natalenko , Paul Menzel , "Guilherme G. Piccoli" , Piotr Gorski , Usama Arif , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, Russell King , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Guo Ren , linux-csky@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E.J. Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , linux-riscv@lists.infradead.org, Mark Rutland , Sabin Rapan , "Michael Kelley (LINUX)" , David Woodhouse Subject: [patch V2 28/38] cpu/hotplug: Reset task stack state in _cpu_up() References: <20230504185733.126511787@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Date: Thu, 4 May 2023 21:02:43 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Woodhouse 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 the idle thread setup will happen at a different step. As a consequence 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 Signed-off-by: Thomas Gleixner Tested-by: Mark Rutland Reviewed-by: Mark Rutland --- kernel/cpu.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -771,12 +771,6 @@ static int bringup_cpu(unsigned int cpu) return -EAGAIN; /* - * 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. * Prevent irq alloc/free across the bringup. @@ -1583,6 +1577,12 @@ static int _cpu_up(unsigned int cpu, int 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;