Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1739371rwd; Thu, 15 Jun 2023 15:10:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5wzV/4p2vSLoCUdm+q8VQRAIsBRjTyGEjis4LOdoEYwTXCDFCbLO2fxHFqi2A7N/3WZWr2 X-Received: by 2002:a05:6a20:d81b:b0:10b:fb01:a72a with SMTP id iv27-20020a056a20d81b00b0010bfb01a72amr562336pzb.60.1686867021273; Thu, 15 Jun 2023 15:10:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686867021; cv=none; d=google.com; s=arc-20160816; b=Dr31DtbhzhV+NTsGBhapQC+jorDqHpt1vLoBxpD8WknDsmOO/Ny4Yyn/B0YsU5q4/F pPjkLuHOv3SvWfjra0zaiHQLjSdnWGVaPg6qYXNMyomlkwf+GnNT3P6EGnm1Usuco6fr 3gADQvdo9stR/p79dhY+zPoBlFnZp3BZna0LcT20oICW2Oc4J9Ry4PWJ1Lf5mK9WWvxd l98MPERAvA7YXGLnkULTXStTQSJcJXVbGZenAfs/EI7xlzfIJTu88M+JV4WVXbVHOhl2 nkf+7lZsiYGY0PKp+74dmngO3+J3aEIXHMxwoiox5k1c8TWnynckpzxZ2VAzBKENQoSf 8nMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=WePTMyE45qwE++8TRrjkwtysmPUcOS3LgW/k38AkuSI=; b=C/JM6vlJUyorOHvOxFBAXE4OeMyWOOVujMwbVlcLF49L93ZWdGCT/PEkhLH5r5yjTc 5cW5xqFdSmQf6aALaL7qgK+hhzfVlGMFja0s4i8rwIeGC4g5m7GUKLFIia2sg+UGKRQ6 sanKoX40U+hkjlNBEk4NyagHb/EawC1VmQF5LjnNr8zHYr6ptaQvxjkk1X9JUKukCDHW tm6PXBHuLwNnJROKRQdhZuGWTIgxxnDUM5FUZO4rUD0f4anoNoU2IlwCC+S/LyoxJjPN KkQTvr8xtXr38IlKZd7zAQbPwXKkVHZJiX7s6pk1xo1cEOKfua0qgUBejOTPx6hTU+D+ MGmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=BFrLebSk; 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 m6-20020a625806000000b00665ff51f7dbsi410896pfb.214.2023.06.15.15.10.08; Thu, 15 Jun 2023 15:10:21 -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=BFrLebSk; 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 S229480AbjFOWDr (ORCPT + 99 others); Thu, 15 Jun 2023 18:03:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231231AbjFOWDh (ORCPT ); Thu, 15 Jun 2023 18: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 1942B2D6B; Thu, 15 Jun 2023 15:03:33 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1686866611; 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: in-reply-to:in-reply-to:references:references; bh=WePTMyE45qwE++8TRrjkwtysmPUcOS3LgW/k38AkuSI=; b=BFrLebSkFNVOCzT2IpgGiJ0Pvwl4C6rJQWMOuiT+63wINu33JzO78MU9TYGFMlnWUXyAUh Xhk4wm8ZUtG+W8XJ1HYlTbHql0VJge25Ax5kGvVg+m6ndfrxbxGCAKdspD5x5j4TmDVxGW hz23M3Hz+IqqiDWtpbQps8Ylv0FhHNkVJiImy19cXSnE3P8f2RAAZmjZTovqVh5T0zERE4 P/0Lx/U4+CDx5K5TMi5xFn2XRxKyjm/1lX7z1RJvE4XZO349M91G/jWdnDwbBd8z42Bqhr R8YBEF4GMDQ+PIIUcGwC4fRAq2j8jxS43fkmJxExYShf33Zc0q093qDMYhFKxw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1686866611; 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: in-reply-to:in-reply-to:references:references; bh=WePTMyE45qwE++8TRrjkwtysmPUcOS3LgW/k38AkuSI=; b=6iNPBBEFXbFtS5Ao2dawxcNVDyr/qHhbmKNIDyn3HuL1jxxTrLdZSnDkEAT/K1svJmXSNt QPnvP4lcgbb0l9Ag== To: "Edgecombe, Rick P" , "linux-kernel@vger.kernel.org" Cc: "chenhuacai@kernel.org" , "darwi@linutronix.de" , "linux-ia64@vger.kernel.org" , "glaubitz@physik.fu-berlin.de" , "Torvalds, Linus" , "chris@zankel.net" , "ysato@users.sourceforge.jp" , "davem@davemloft.net" , "thomas.lendacky@amd.com" , "James.Bottomley@HansenPartnership.com" , "mpe@ellerman.id.au" , "kernel@xen0n.name" , "linux-sh@vger.kernel.org" , "dalias@libc.org" , "loongarch@lists.linux.dev" , "linux@armlinux.org.uk" , "linux-m68k@lists.linux-m68k.org" , "nik.borisov@suse.com" , "arnd@arndb.de" , "anton.ivanov@cambridgegreys.com" , "sparclinux@vger.kernel.org" , "richard@nod.at" , "johannes@sipsolutions.net" , "linux-um@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "tsbogend@alpha.franken.de" , "linux-mips@vger.kernel.org" , "richard.henderson@linaro.org" , "geert@linux-m68k.org" , "x86@kernel.org" Subject: Re: [patch 12/17] init: Invoke arch_cpu_finalize_init() earlier In-Reply-To: References: <20230613223827.532680283@linutronix.de> <20230613224545.612182854@linutronix.de> Date: Fri, 16 Jun 2023 00:03:30 +0200 Message-ID: <87sfas758t.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain 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 autolearn=unavailable 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 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 > > 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?