]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
powerpc/pseries: Perform full re-add of CPU for topology update post-migration
authorNathan Fontenot <nfont@linux.vnet.ibm.com>
Mon, 29 Oct 2018 18:43:36 +0000 (13:43 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 5 Apr 2019 20:33:13 +0000 (22:33 +0200)
commit06af7dda05b33fe7b37bdf95b87e944b2e2de608
treefff68656c928feeb418515a2ed587c18f5319a7f
parent57f03bbd42363b8e6287acc4116c676c99807080
powerpc/pseries: Perform full re-add of CPU for topology update post-migration

[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]

On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
post-migration on the destination system CPUs are in nodes 2 and 3.

Handling the node change for a CPU can cause corruption in the slab
cache if we hit a timing where a CPUs node is changed while cache_reap()
is invoked. The corruption occurs because the slab cache code appears
to rely on the CPU and slab cache pages being on the same node.

The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
does not prevent us from hitting this scenario.

Changing the device tree property update notification handler that
recognizes an affinity change for a CPU to do a full DLPAR remove and
add of the CPU instead of dynamically changing its node resolves this
issue.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Tested-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/powerpc/include/asm/topology.h
arch/powerpc/mm/numa.c
arch/powerpc/platforms/pseries/hotplug-cpu.c