From: Peter Zijlstra <peterz@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Yunsheng Lin <linyunsheng@huawei.com>,
Greg KH <gregkh@linuxfoundation.org>,
rafael@kernel.org, linux-kernel@vger.kernel.org,
mingo@kernel.org, linuxarm@huawei.com
Subject: Re: [PATCH] driver core: ensure a device has valid node id in device_add()
Date: Mon, 23 Sep 2019 17:09:42 +0200 [thread overview]
Message-ID: <20190923150942.GD2369@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190911064926.GJ4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 08:49:26AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 14:15:51, Yunsheng Lin wrote:
> > >>>>>> When passing the return value of dev_to_node() to cpumask_of_node()
> > >>>>>> without checking the node id if the node id is not valid, there is
> > >>>>>> global-out-of-bounds detected by KASAN as below:
> > >>>>>
> > >>>>> OK, I seem to remember this being brought up already. And now when I
> > >>>>> think about it, we really want to make cpumask_of_node NUMA_NO_NODE
> > >>>>> aware. That means using the same trick the allocator does for this
> > >>>>> special case.
> No. Please read the above paragraph again. NUMA_NO_NODE really means no
> node affinity. So all cpus should be usable. Making any assumptions
> about a local context is just wrong.
So none of this makes sense to me. How can a device have NUMA_NO_NODE on
a NUMA machine. It needs to have a physical presence _somwhere_; and
that cannot be equidistant from all CPUs.
Please explain how this makes physical sense.
next prev parent reply other threads:[~2019-09-23 15:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 6:04 [PATCH] driver core: ensure a device has valid node id in device_add() Yunsheng Lin
2019-09-09 9:53 ` Greg KH
2019-09-10 6:43 ` Yunsheng Lin
2019-09-10 7:13 ` Michal Hocko
2019-09-10 9:31 ` Greg KH
2019-09-10 10:58 ` Yunsheng Lin
2019-09-10 11:04 ` Michal Hocko
2019-09-10 11:12 ` Greg KH
2019-09-10 12:47 ` Yunsheng Lin
2019-09-10 12:53 ` Michal Hocko
2019-09-11 5:33 ` Michal Hocko
2019-09-11 6:15 ` Yunsheng Lin
2019-09-11 6:49 ` Michal Hocko
2019-09-11 7:22 ` Yunsheng Lin
2019-09-11 7:34 ` Michal Hocko
2019-09-11 11:03 ` Yunsheng Lin
2019-09-11 11:41 ` Yunsheng Lin
2019-09-11 12:02 ` Michal Hocko
2019-09-23 15:09 ` Peter Zijlstra [this message]
2019-09-09 18:50 ` Michal Hocko
2019-09-10 7:08 ` Yunsheng Lin
2019-09-10 7:24 ` Michal Hocko
2019-09-10 10:40 ` Yunsheng Lin
2019-09-10 11:01 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190923150942.GD2369@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=linyunsheng@huawei.com \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.