linux-kernel - Re: [PATCH v4 08/10] powerpc/pseries: Initialise CPU hotplug callbacks earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230814105107.kvsqhlzvlggjddnw@linux.vnet.ibm.com>
Date:   Mon, 14 Aug 2023 16:21:07 +0530
From:   Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:     Laurent Dufour <ldufour@...ux.ibm.com>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-arch@...r.kernel.org,
        dave.hansen@...ux.intel.com, linux-kernel@...r.kernel.org,
        mingo@...hat.com, bp@...en8.de, npiggin@...il.com,
        tglx@...utronix.de, rui.zhang@...el.com
Subject: Re: [PATCH v4 08/10] powerpc/pseries: Initialise CPU hotplug
 callbacks earlier

* Laurent Dufour <ldufour@...ux.ibm.com> [2023-07-05 16:51:41]:

> From: Michael Ellerman <mpe@...erman.id.au>
> 
> As part of the generic HOTPLUG_SMT code, there is support for disabling
> secondary SMT threads at boot time, by passing "nosmt" on the kernel
> command line.
> 
> The way that is implemented is the secondary threads are brought partly
> online, and then taken back offline again. That is done to support x86
> CPUs needing certain initialisation done on all threads. However powerpc
> has similar needs, see commit d70a54e2d085 ("powerpc/powernv: Ignore
> smt-enabled on Power8 and later").
> 
> For that to work the powerpc CPU hotplug callbacks need to be registered
> before secondary CPUs are brought online, otherwise __cpu_disable()
> fails due to smp_ops->cpu_disable being NULL.
> 
> So split the basic initialisation into pseries_cpu_hotplug_init() which
> can be called early from setup_arch(). The DLPAR related initialisation
> can still be done later, because it needs to do allocations.
> 

Looks good to me.

Reviewed-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>

> Signed-off-by: Michael Ellerman <mpe@...erman.id.au>

-- 
Thanks and Regards
Srikar Dronamraju