From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33457C49ED9 for ; Thu, 12 Sep 2019 10:36:09 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76E08206A5 for ; Thu, 12 Sep 2019 10:36:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76E08206A5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46TZtY3Mt2zDr5L for ; Thu, 12 Sep 2019 20:36:05 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=huawei.com (client-ip=45.249.212.32; helo=huawei.com; envelope-from=linyunsheng@huawei.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=huawei.com Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46TZTs5W32zF48Y for ; Thu, 12 Sep 2019 20:18:09 +1000 (AEST) Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 66E23A1E9E63440E65DF; Thu, 12 Sep 2019 18:18:02 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.439.0; Thu, 12 Sep 2019 18:17:57 +0800 From: Yunsheng Lin To: , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v3 6/8] sparc64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for sparc64 Date: Thu, 12 Sep 2019 18:15:32 +0800 Message-ID: <1568283334-178380-7-git-send-email-linyunsheng@huawei.com> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1568283334-178380-1-git-send-email-linyunsheng@huawei.com> References: <1568283334-178380-1-git-send-email-linyunsheng@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-sh@vger.kernel.org, peterz@infradead.org, dave.hansen@linux.intel.com, linux-mips@vger.kernel.org, mwb@linux.vnet.ibm.com, hpa@zytor.com, sparclinux@vger.kernel.org, linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com, dledford@redhat.com, jeffrey.t.kirsher@intel.com, naveen.n.rao@linux.vnet.ibm.com, len.brown@intel.com, anshuman.khandual@arm.com, gregkh@linuxfoundation.org, cai@lca.pw, luto@kernel.org, tglx@linutronix.de, mhocko@kernel.org, linux-arm-kernel@lists.infradead.org, axboe@kernel.dk, robin.murphy@arm.com, linux-kernel@vger.kernel.org, tbogendoerfer@suse.de, linux-alpha@vger.kernel.org, rafael@kernel.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So the cpumask_of_node() should always return all cpus online when user passes the node id as NUMA_NO_NODE, just like similar semantic that page allocator handles NUMA_NO_NODE. But we cannot really copy the page allocator logic. Simply because the page allocator doesn't enforce the near node affinity. It just picks it up as a preferred node but then it is free to fallback to any other numa node. This is not the case here and node_to_cpumask_map will only restrict to the particular node's cpus which would have really non deterministic behavior depending on where the code is executed. So in fact we really want to return cpu_online_mask for NUMA_NO_NODE. Since this arch was already NUMA_NO_NODE aware, this patch only changes it to return cpu_online_mask and use NUMA_NO_NODE instead of "-1". [1] https://lore.kernel.org/patchwork/patch/1125789/ Signed-off-by: Yunsheng Lin Suggested-by: Michal Hocko --- V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask for NUMA_NO_NODE case, and change the commit log to better justify the change. --- arch/sparc/include/asm/topology_64.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/include/asm/topology_64.h b/arch/sparc/include/asm/topology_64.h index 34c628a..34f9240 100644 --- a/arch/sparc/include/asm/topology_64.h +++ b/arch/sparc/include/asm/topology_64.h @@ -11,8 +11,8 @@ static inline int cpu_to_node(int cpu) return numa_cpu_lookup_table[cpu]; } -#define cpumask_of_node(node) ((node) == -1 ? \ - cpu_all_mask : \ +#define cpumask_of_node(node) ((node) == NUMA_NO_NODE ? \ + cpu_online_mask : \ &numa_cpumask_lookup_table[node]) struct pci_bus; -- 2.8.1