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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 BA603C4360C for ; Sat, 12 Oct 2019 06:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 948AD2089C for ; Sat, 12 Oct 2019 06:17:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728111AbfJLGR6 (ORCPT ); Sat, 12 Oct 2019 02:17:58 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:50222 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726947AbfJLGR5 (ORCPT ); Sat, 12 Oct 2019 02:17:57 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 3323C80206F36887AE0D; Sat, 12 Oct 2019 14:17:54 +0800 (CST) Received: from [127.0.0.1] (10.74.191.121) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.439.0; Sat, 12 Oct 2019 14:17:52 +0800 Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware To: Peter Zijlstra CC: Michal Hocko , Robin Murphy , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "Rafael J. Wysocki" , , References: <20190924124325.GQ2349@hirez.programming.kicks-ass.net> <20190924125936.GR2349@hirez.programming.kicks-ass.net> <20190924131939.GS23050@dhcp22.suse.cz> <1adcbe68-6753-3497-48a0-cc84ac503372@huawei.com> <20190925104108.GE4553@hirez.programming.kicks-ass.net> <47fa4cee-8528-7c23-c7de-7be1b65aa2ae@huawei.com> <20191010073212.GB18412@dhcp22.suse.cz> <6cc94f9b-0d79-93a8-5ec2-4f6c21639268@huawei.com> <20191011111539.GX2311@hirez.programming.kicks-ass.net> From: Yunsheng Lin Message-ID: <7fad58d6-5126-e8b8-a7d8-a91814da53ba@huawei.com> Date: Sat, 12 Oct 2019 14:17:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20191011111539.GX2311@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.74.191.121] X-CFilter-Loop: Reflected Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org add pci and acpi maintainer cc linux-pci@vger.kernel.org and linux-acpi@vger.kernel.org On 2019/10/11 19:15, Peter Zijlstra wrote: > On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: >> But I failed to see why the above is related to making node_to_cpumask_map() >> NUMA_NO_NODE aware? > > Your initial bug is for hns3, which is a PCI device, which really _MUST_ > have a node assigned. > > It not having one, is a straight up bug. We must not silently accept > NO_NODE there, ever. > I suppose you mean reporting a lack of affinity when the node of a pcie device is not set by "not silently accept NO_NODE". As Greg has asked about in [1]: what is a user to do when the user sees the kernel reporting that? We may tell user to contact their vendor for info or updates about that when they do not know about their system well enough, but their vendor may get away with this by quoting ACPI spec as the spec considering this optional. Should the user believe this is indeed a fw bug or a misreport from the kernel? If this kind of reporting is common pratice and will not cause any misunderstanding, then maybe we can report that. [1] https://lore.kernel.org/lkml/20190905055727.GB23826@kroah.com/ > . >