Message ID | 20230613224545.612182854@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp891538vqr; Tue, 13 Jun 2023 16:42:14 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7+1O80vI0zuUph8KNEwJqMIY7EVTwZ50ncXrn6yLksoy2IuYb77p26Hmm0Ze4C4JzdM3GS X-Received: by 2002:a17:907:6d0e:b0:973:f72f:dfac with SMTP id sa14-20020a1709076d0e00b00973f72fdfacmr10718242ejc.67.1686699734363; Tue, 13 Jun 2023 16:42:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686699734; cv=none; d=google.com; s=arc-20160816; b=Ss/fCayyYMVplrbuAUxyol4NYlmmJbiui962wYZ/HgHcJuLqx2wOyUKwCzC26H3Mi6 hAy0I+WzkZicw+Si14NuY+k4moEr9xqdGvzL5q5qQ4pcWhSJJDEVT+qT8TvNzGjf+HC9 to4TmoBGh5gO5QPY8jUStF9qU1vEpIkyduiMstAqV9rkbqrZKBq5g/+SV2S3m7NzVCpn ULaG9dG5NjX5gQ80y4TpZd/kebP0tsRSkFLO8/Q0DVQ55Pgr9dBVoK1g444hA3G+YH4A lKymTcfjrrH1qulxOuiZUg230rOSngG4L4jrXvI2UfAVZzR7TAVLLQmrTkATjMYCeqqs 3/Xg== 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=0VnFCDlFg0Z65xUPcTSUW8cd097ZM3tj8m6sSpK3s64=; b=0041ivSKDRjtyTHu0/63gXHGD7FQsh76ONPb9BlF90kCe7v7KKj3yNTwRaZ43aahVD RxiYuGVmmdqLm5+ltlAsAcftc5RgJMT/Ck8nEgUm9VeqJ8edxSdhaXoN7Z7shX+eBU0k YyimQXjd8V0ERYl4pFEGql/rMFRxFZXFx9QPmb5ktDejfxgGZH1dDXcL57fxiEUgW7FZ jbQGY9pHf60rKnGo04zEm3RFnsBo07zWjzVrDrQjTjQWvNbVdAWsYqlkhH0ARbmIEDUn omj9HBvOAzt8u7yeCBryaVAAdwylEcp3MQqL98M4I0XG7yO5RdTbLoI8NT4j/Yfl7GQ1 WFFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=2vIwQPIU; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; 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 z14-20020a170906074e00b0097462aacd20si6948911ejb.493.2023.06.13.16.41.49; Tue, 13 Jun 2023 16:42:14 -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=2vIwQPIU; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; 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 S231987AbjFMXlC (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Tue, 13 Jun 2023 19:41:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241534AbjFMXkE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 13 Jun 2023 19:40:04 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F9F51FFB; Tue, 13 Jun 2023 16:39:41 -0700 (PDT) Message-ID: <20230613224545.612182854@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1686699580; 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=0VnFCDlFg0Z65xUPcTSUW8cd097ZM3tj8m6sSpK3s64=; b=2vIwQPIUp/HJUmCG4BQezI45Q367xKHJYYqLK7G4wdrDSn+cOBFzLkdHYUwzUXc6gDifT9 rXY1lpsCnLehM7zAXb6roxx5XLRXYnCJR+grAmVc2dHif25zyPdBFAdRB8oZi5F8oDEYjX LfRMBrXHCi+WgVWwvhW/rD4N9Ur83iWtMYD/8dwxcO3p39WY5cZNs0IUmsHtiYOfpH2mPn zfJVRybOawF0SSzGOD7ZbR8K3/Wde2+WMR35K0mYj4U05gliICM7VVvC+XUr8nRG+osE42 Jt6Rw45sBhht2PYfVT0AcDzOMXI7pmmP+pQ2CC66euAz7R6Cd8BF8y04Prxn9g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1686699580; 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=0VnFCDlFg0Z65xUPcTSUW8cd097ZM3tj8m6sSpK3s64=; b=Xu1aR4gK/TE/PO7y3dM5tqNyYP8UwrzsrU8JCSaOdKEVqSuAOvhIQ2kubFuP8M//eeln2X Z4Xwxgc0BSAFJ1Bg== From: Thomas Gleixner <tglx@linutronix.de> To: LKML <linux-kernel@vger.kernel.org> Cc: x86@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Nikolay Borisov <nik.borisov@suse.com>, "Ahmed S. Darwish" <darwi@linutronix.de>, Arnd Bergmann <arnd@arndb.de>, Russell King <linux@armlinux.org.uk>, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, loongarch@lists.linux.dev, Geert Uytterhoeven <geert@linux-m68k.org>, linux-m68k@lists.linux-m68k.org, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, linux-mips@vger.kernel.org, Yoshinori Sato <ysato@users.sourceforge.jp>, Rich Felker <dalias@libc.org>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, linux-sh@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, sparclinux@vger.kernel.org, Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, linux-um@lists.infradead.org, Richard Henderson <richard.henderson@linaro.org>, "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>, Michael Ellerman <mpe@ellerman.id.au>, Chris Zankel <chris@zankel.net>, Tom Lendacky <thomas.lendacky@amd.com> Subject: [patch 12/17] init: Invoke arch_cpu_finalize_init() earlier References: <20230613223827.532680283@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Date: Wed, 14 Jun 2023 01:39:39 +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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768632860445622703?= X-GMAIL-MSGID: =?utf-8?q?1768632860445622703?= |
Series |
init, treewide, x86: Cleanup check_bugs() and start sanitizing the x86 boot process
|
|
Commit Message
Thomas Gleixner
June 13, 2023, 11:39 p.m. UTC
X86 is reworking the boot process so that initializations which are not
required during early boot can be moved into the late boot process and out
of the fragile and restricted initial boot phase.
arch_cpu_finalize_init() is the obvious place to do such initializations,
but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for
initializing the FPU completely. fork_init() requires that the FPU is
initialized as the size of task_struct on X86 depends on the size of the
required FPU register buffer.
Fortunately none of the init calls between calibrate_delay() and
arch_cpu_finalize_init() is relevant for the functionality of
arch_cpu_finalize_init().
Invoke it right after calibrate_delay() where everything which is relevant
for arch_cpu_finalize_init() has been set up already.
No functional change intended.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
init/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Wed, 2023-06-14 at 01:39 +0200, Thomas Gleixner wrote: > Fortunately none of the init calls between calibrate_delay() and > arch_cpu_finalize_init() is relevant for the functionality of > arch_cpu_finalize_init(). > Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> I did my best to find a counterpoint to this statement. The only thing I found was that lockdep_init_task(&init_task) in fork_init() is now called after the spin_lock() usage in set_memory_4k(). But AFAICT, that whole lockdep_init_task() call is unneeded because the fields it sets are already statically initialized. I mention only because I'm not 100% sure the lockdep_init_task() call is not serving some purpose I'm missing.
On Thu, Jun 15 2023 at 21:44, Rick P. Edgecombe wrote: > On Wed, 2023-06-14 at 01:39 +0200, Thomas Gleixner wrote: >> Fortunately none of the init calls between calibrate_delay() and >> arch_cpu_finalize_init() is relevant for the functionality of >> arch_cpu_finalize_init(). >> > > Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> > > I did my best to find a counterpoint to this statement. The only thing > I found was that lockdep_init_task(&init_task) in fork_init() is now > called after the spin_lock() usage in set_memory_4k(). > > But AFAICT, that whole lockdep_init_task() call is unneeded because > the fields it sets are already statically initialized. Correct. The call there looks absolute pointless. Peter?
--- a/init/main.c +++ b/init/main.c @@ -1041,6 +1041,8 @@ asmlinkage __visible void __init __no_sa sched_clock_init(); calibrate_delay(); + arch_cpu_finalize_init(); + /* * This needs to be called before any devices perform DMA * operations that might use the SWIOTLB bounce buffers. It will @@ -1077,8 +1079,6 @@ asmlinkage __visible void __init __no_sa taskstats_init_early(); delayacct_init(); - arch_cpu_finalize_init(); - acpi_subsystem_init(); arch_post_acpi_subsys_init(); kcsan_init();