Received: by 10.223.185.116 with SMTP id b49csp1029912wrg; Wed, 21 Feb 2018 10:51:44 -0800 (PST) X-Google-Smtp-Source: AH8x224cXvWc9IEFl53YdKZvSk+otAQ9movIHGL8AZBM9nPRfGZxz8n71sUSKp/9NKSemd5RI6Mb X-Received: by 2002:a17:902:2904:: with SMTP id g4-v6mr3956789plb.170.1519239104172; Wed, 21 Feb 2018 10:51:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519239104; cv=none; d=google.com; s=arc-20160816; b=y1mwk9wMnV5FTFG+oWxV4GmeGiKLtCcHMHAScuefmlMHmF9CW0CsDVV1Iumf6yLb0a LYKwoKu42Acjdq4j3qUarjFyFI/3hmO/0cGWNIrLRzh3GvKNaixE+zdkKZD83uGyINeK 6atmXitovmWmN8RGKGkPjcmZpDkkqIo9U1DgKRUEMF/jkTFtk4ywcPKLHpKN2ZIb5pxE nlq7VI7t+C8oGD+fVUQfghFSGTbFxRF+LG+Wt5aXKCmpmpL/gi2Id1vCtOabdKz1E19x Rqqs4Y0lH9nQtw6UYApFBDxj6Zh4Qnb0q0utnDdJrZ+oTcY0QbSSr30CoxzRV/pmibLf MPaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=0lRoQ57F3IN2evr0VjxGYpEgWdc1wKd82UDzcm6cIPk=; b=vJjHXdsu3JmUvcBMLxu605Slr26Tc7hjpZNUFfcNEOqAPx1FiDNRYCNMv1olXv/6qF anoDT2nED89g+yv2UvEE8T1cmr6zYVj7Fr6AkWhD8W4/G049NGVZKwvaKmPbCDALOu3c 6RiyZTxtJwH0xQNtHAgkXnEcPjPrBYuB2wJVYXde6ex9kygZmIv9+2hVelsSACB74Gya RSTnbDNOY4qL0p7Nwi86DdSiSlwmmjoUM/C/5DVHfSTxC8wJv7QAc0nSRYtjVzBGev09 5038eUCbTEXF/RpPswGwpO7sRgJ/XXO24f4RsRXyS0sJtOc/KMPnF9JY9VEAAsO2vTCW vWNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c5-v6si1750465pll.90.2018.02.21.10.51.30; Wed, 21 Feb 2018 10:51:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965895AbeBUOVq (ORCPT + 99 others); Wed, 21 Feb 2018 09:21:46 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:36132 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934912AbeBUM61 (ORCPT ); Wed, 21 Feb 2018 07:58:27 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 8D9A5FAD; Wed, 21 Feb 2018 12:58:26 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nathan Fontenot , Tyrel Datwyler , Michael Ellerman Subject: [PATCH 4.14 020/167] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove Date: Wed, 21 Feb 2018 13:47:11 +0100 Message-Id: <20180221124525.710499299@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180221124524.639039577@linuxfoundation.org> References: <20180221124524.639039577@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nathan Fontenot commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream. When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: stable@vger.kernel.org Signed-off-by: Nathan Fontenot Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/include/asm/topology.h | 5 +++++ arch/powerpc/mm/numa.c | 5 ----- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++ 3 files changed, 7 insertions(+), 5 deletions(-) --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -44,6 +44,11 @@ extern int sysfs_add_device_to_node(stru extern void sysfs_remove_device_from_node(struct device *dev, int nid); extern int numa_update_cpu_topology(bool cpus_locked); +static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) +{ + numa_cpu_lookup_table[cpu] = node; +} + static inline int early_cpu_to_node(int cpu) { int nid; --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -142,11 +142,6 @@ static void reset_numa_cpu_lookup_table( numa_cpu_lookup_table[cpu] = -1; } -static void update_numa_cpu_lookup_table(unsigned int cpu, int node) -{ - numa_cpu_lookup_table[cpu] = node; -} - static void map_cpu_to_node(int cpu, int node) { update_numa_cpu_lookup_table(cpu, node); --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -36,6 +36,7 @@ #include #include #include +#include #include "pseries.h" #include "offline_states.h" @@ -331,6 +332,7 @@ static void pseries_remove_processor(str BUG_ON(cpu_online(cpu)); set_cpu_present(cpu, false); set_hard_smp_processor_id(cpu, -1); + update_numa_cpu_lookup_table(cpu, -1); break; } if (cpu >= nr_cpu_ids)