From patchwork Fri May 12 21:07:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 93383 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp5395670vqo; Fri, 12 May 2023 14:17:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5pvDDjgyqEY7n3VFDGBda2dciSCaPFBD145a7iIQBthHki9j7XeARJwaKPBbiAozixzQOU X-Received: by 2002:a05:6a20:748c:b0:104:ffd0:2338 with SMTP id p12-20020a056a20748c00b00104ffd02338mr486726pzd.26.1683926250945; Fri, 12 May 2023 14:17:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683926250; cv=none; d=google.com; s=arc-20160816; b=Cb35N8gUmC+DSrHGlUPi8ipyM2NMAZWsiUEivWCodjNM418FsrSkjzpQM8uNn7fVkb CesO9xSB8xAbatmRaJmNc6zOn9NcA4pJE7pRkUx2Ht9EXQhhVUqXWUMzavO3goydQiiR VHqeqph7ft0crToWWIvH3c8YLbzWof8BnF1Z669RPyrGQpweOCNOH1SgUnYdsLQiu1wu TMbrqKU+I+eBSIE3T5F2t+Wha/Xw0mLwx1H13YAj3bPXhideea3J+AJU9aBDQ216y70k opiB+MstbA+6I3a5IUK3YlFfF41NGHhWx9nuSxHoaWNes7SxgiMPupssTnNvHfQO+TMx zjWg== 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=CERacbFmAU0r2YyiKnQSCmUMCfPrzAHfru8m3ZNl0KY=; b=mWMVbum8RuyAi+/koTa+2V9Met4KyETxj+pp0OMInwF+PCahRyqeZej8tKf6+KysaR 3uUAzu1s13xXS58L9B4ujBW1X6et8o9wRByp8mDmAzuhFhiCeYXYBZNo4GYdqrd5aHZr JBA9D+/dGKoYZ1F0wBg1OCfMqul/apM+jZbzMEQD447XUMAkJ0IfN1fKXg3yIPJcYcnk EgYUyNJ5RLLkALu4F9yvg542IptxQiCZS9fN5LiJd6ujXutUmjjztzQzqFCR6FaSoxeV xJvRJAnliW7tQZ0eIR2YMgeStjus8awRli08RyX/jkGEYxqA5mMMWsC0G8yU1OQs0ikG MPmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=mlVKNpwr; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="pI9Kl0/a"; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m24-20020a637118000000b00518db33cf17si9906323pgc.552.2023.05.12.14.17.18; Fri, 12 May 2023 14:17:30 -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=mlVKNpwr; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="pI9Kl0/a"; 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 S239452AbjELVHm (ORCPT + 99 others); Fri, 12 May 2023 17:07:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239180AbjELVHb (ORCPT ); Fri, 12 May 2023 17:07:31 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A168DD052; Fri, 12 May 2023 14:07:11 -0700 (PDT) Message-ID: <20230512205255.875713771@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1683925630; 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=CERacbFmAU0r2YyiKnQSCmUMCfPrzAHfru8m3ZNl0KY=; b=mlVKNpwrrZo8g1O5g2m+Me4aq4cJcRqHlfaggouQckkiLNuNl3gMI9wJGW+qTK77NJ8L1t BNZic2MIATVICLudtbI4AZFCsrK6yBKlMcV3RCwHbtApC9WMnfOTf/384jFhT6DDyDkJLU 68mjGx+kFnbdgLpBHRHDsZybKUUSd4DCRTEkmrpezylPkqkyKvPz75OmYdO3ljKUmH8DT+ qileb82DTQnWi+EWLiBSaCU365hMQBR6WvjZdiFAVtGRc9MA/Xyms7EJNSpFNCUC672GYD N9c4DHYS2yGrtOZTD5VUq08pLhp9Cqoy87Bcu1VdvrO1+17UGGzGP2jJGlQcVA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1683925630; 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=CERacbFmAU0r2YyiKnQSCmUMCfPrzAHfru8m3ZNl0KY=; b=pI9Kl0/aVsNuuAI/L8tX3o8uA++5XGmGpbq0v8JJXHVuwg59C4dNMi5XaYjRi8u2L2df6G eiU05lrMbsKzBPAA== 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)" , Ross Philipson , Peter Zijlstra Subject: [patch V4 08/37] x86/smpboot: Remove unnecessary barrier() References: <20230512203426.452963764@linutronix.de> MIME-Version: 1.0 Date: Fri, 12 May 2023 23:07:09 +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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765724652534823355?= X-GMAIL-MSGID: =?utf-8?q?1765724652534823355?= Peter stumbled over the barrier() after the invocation of smp_callin() in start_secondary(): "...this barrier() and it's comment seem weird vs smp_callin(). That function ends with an atomic bitop (it has to, at the very least it must not be weaker than store-release) but also has an explicit wmb() to order setup vs CPU_STARTING. There is no way the smp_processor_id() referred to in this comment can land before cpu_init() even without the barrier()." The barrier() along with the comment was added in 2003 with commit d8f19f2cac70 ("[PATCH] x86-64 merge") in the history tree. One of those well documented combo patches of that time which changes world and some more. The context back then was: /* * Dont put anything before smp_callin(), SMP * booting is too fragile that we want to limit the * things done here to the most necessary things. */ cpu_init(); smp_callin(); + /* otherwise gcc will move up smp_processor_id before the cpu_init */ + barrier(); Dprintk("cpu %d: waiting for commence\n", smp_processor_id()); Even back in 2003 the compiler was not allowed to reorder that smp_processor_id() invocation before the cpu_init() function call. Especially not as smp_processor_id() resolved to: asm volatile("movl %%gs:%c1,%0":"=r" (ret__):"i"(pda_offset(field)):"memory"); There is no trace of this change in any mailing list archive including the back then official x86_64 list discuss@x86-64.org, which would explain the problem this change solved. The debug prints are gone by now and the the only smp_processor_id() invocation today is farther down in start_secondary() after locking vector_lock which itself prevents reordering. Even if the compiler would be allowed to reorder this, the code would still be correct as GSBASE is set up early in the assembly code and is valid when the CPU reaches start_secondary(), while the code at the time when this barrier was added did the GSBASE setup in cpu_init(). As the barrier has zero value, remove it. Reported-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20230509100421.GU83892@hirez.programming.kicks-ass.net --- V4: New patch --- arch/x86/kernel/smpboot.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -238,8 +238,6 @@ static void notrace start_secondary(void x86_cpuinit.early_percpu_clock_init(); smp_callin(); - /* otherwise gcc will move up smp_processor_id before the cpu_init */ - barrier(); /* Check TSC synchronization with the control CPU: */ check_tsc_sync_target();