On Mon 23-09-19 17:15:19, Peter Zijlstra wrote: > On Tue, Sep 17, 2019 at 08:48:54PM +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://lore.kernel.org/patchwork/patch/1125789/ > > That is bloody unusable, don't do that. Use: > > https://lkml.kernel.org/r/$MSGID > > if anything. Then I can find it in my local mbox without having to > resort to touching a mouse and shitty browser software. > > (also patchwork is absolute crap for reading email threads) > > Anyway, I found it -- I think, I refused to click the link. I replied > there. > > > Signed-off-by: Yunsheng Lin <linyunsh...@huawei.com> > > Suggested-by: Michal Hocko <mho...@kernel.org> > > Acked-by: Michal Hocko <mho...@suse.com> > > > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > > index 4123100e..9859acb 100644 > > --- a/arch/x86/mm/numa.c > > +++ b/arch/x86/mm/numa.c > > @@ -861,6 +861,9 @@ void numa_remove_cpu(int cpu) > > */ > > const struct cpumask *cpumask_of_node(int node) > > { > > + if (node == NUMA_NO_NODE) > > + return cpu_online_mask; > > This mandates the caller holds cpus_read_lock() or something, I'm pretty > sure that if I put: > > lockdep_assert_cpus_held();
Is this documented somewhere? Also how does that differ from a normal case when a proper node is used? The cpumask will always be dynamic in the cpu hotplug presence, right? > here, it comes apart real quick. Without holding the cpu hotplug lock, > the online mask is gibberish. Can the returned cpu mask go away? -- Michal Hocko SUSE Labs
