Michael Bringmann <m...@linux.vnet.ibm.com> writes: > On 1/29/19 3:37 AM, Michael Ellerman wrote: >> Michael Bringmann <m...@linux.vnet.ibm.com> writes: >> >>> On 10/29/18 1:43 PM, Nathan Fontenot wrote: >>>> 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 <nf...@linux.vnet.ibm.com >>> Signed-off-by: Michael W. Bringmann <m...@linux.vnet.ibm.com> > > Tested-by: Michael W. Bringmann <m...@linux.vnet.ibm.com>
Thanks. cheers