linux-kernel - Re: [PATCH v7] numa: make node_to_cpumask_map() NUMA_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f7aa833e-3ed3-aba0-8c6e-8753a68182c2@huawei.com>
Date:   Thu, 31 Oct 2019 11:26:04 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <catalin.marinas@....com>, <will@...nel.org>, <mingo@...hat.com>,
        <bp@...en8.de>, <rth@...ddle.net>, <ink@...assic.park.msu.ru>,
        <mattst88@...il.com>, <benh@...nel.crashing.org>,
        <paulus@...ba.org>, <mpe@...erman.id.au>,
        <heiko.carstens@...ibm.com>, <gor@...ux.ibm.com>,
        <borntraeger@...ibm.com>, <ysato@...rs.sourceforge.jp>,
        <dalias@...c.org>, <davem@...emloft.net>, <ralf@...ux-mips.org>,
        <paul.burton@...s.com>, <jhogan@...nel.org>,
        <jiaxun.yang@...goat.com>, <chenhc@...ote.com>,
        <akpm@...ux-foundation.org>, <rppt@...ux.ibm.com>,
        <anshuman.khandual@....com>, <tglx@...utronix.de>, <cai@....pw>,
        <robin.murphy@....com>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <hpa@...or.com>, <x86@...nel.org>,
        <dave.hansen@...ux.intel.com>, <luto@...nel.org>,
        <len.brown@...el.com>, <axboe@...nel.dk>, <dledford@...hat.com>,
        <jeffrey.t.kirsher@...el.com>, <linux-alpha@...r.kernel.org>,
        <naveen.n.rao@...ux.vnet.ibm.com>, <mwb@...ux.vnet.ibm.com>,
        <linuxppc-dev@...ts.ozlabs.org>, <linux-s390@...r.kernel.org>,
        <linux-sh@...r.kernel.org>, <sparclinux@...r.kernel.org>,
        <tbogendoerfer@...e.de>, <linux-mips@...r.kernel.org>,
        <rafael@...nel.org>, <mhocko@...nel.org>,
        <gregkh@...uxfoundation.org>, <bhelgaas@...gle.com>,
        <linux-pci@...r.kernel.org>, <rjw@...ysocki.net>,
        <lenb@...nel.org>, <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v7] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/10/30 18:14, Peter Zijlstra wrote:
> On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's 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.
>>
>> Also there is a debugging version of node_to_cpumask_map() for x86 and
>> arm64, which is only used when CONFIG_DEBUG_PER_CPU_MAPS is defined, this
>> patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map().
>>
>> [1] https://lkml.org/lkml/2019/9/11/66
>> Signed-off-by: Yunsheng Lin <linyunsheng@...wei.com>
>> Suggested-by: Michal Hocko <mhocko@...nel.org>
>> Acked-by: Michal Hocko <mhocko@...e.com>
>> Acked-by: Paul Burton <paul.burton@...s.com> # MIPS bits
> 
> Still:
> 
> Nacked-by: Peter Zijlstra (Intel) <peterz@...radead.org>

It seems I still misunderstood your meaning by "We must not silently accept
NO_NODE there" in [1].

I am not sure if there is still disagreement that the NO_NODE state for
dev->numa_node should exist at all.

>From the previous disscussion [2], you seem to propose to do "wild guess" or
"fixup" for all devices(including virtual and physcial) with NO_NODE, which means
the NO_NODE is needed anymore and should be removed when the "wild guess" or "fixup"
is done. So maybe the reason for your nack here it is that there should be no other
NO_NODE handling or fixing related to NO_NODE before the "wild guess" or "fixup"
process is finished, so making node_to_cpumask_map() NUMA_NO_NODE aware is unnecessary.

Or your reason for the nack is still specific to the pcie device without a numa node,
the "wild guess" need to be done for this case before making node_to_cpumask_map()
NUMA_NO_NODE?

Please help to clarify the reason for nack. Or is there still some other reason for the
nack I missed from the previous disscussion?

Thanks.

[1] https://lore.kernel.org/lkml/20191011111539.GX2311@hirez.programming.kicks-ass.net/
[2] https://lore.kernel.org/lkml/20191014094912.GY2311@hirez.programming.kicks-ass.net/
> 
> .
>