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
> > >>
On Wed 11-09-19 19:41:44, Yunsheng Lin wrote:
> On 2019/9/11 19:03, Yunsheng Lin wrote:
> > On 2019/9/11 15:34, Michal Hocko wrote:
> >> On Wed 11-09-19 15:22:30, Yunsheng Lin wrote:
> >> [...]
> >>> It seems that there is no protection that prevent setting the node
> >>> of device to an invalid
On 2019/9/11 19:03, Yunsheng Lin wrote:
> On 2019/9/11 15:34, Michal Hocko wrote:
>> On Wed 11-09-19 15:22:30, Yunsheng Lin wrote:
>> [...]
>>> It seems that there is no protection that prevent setting the node
>>> of device to an invalid node.
>>> And the kernel does have a few different check
On 2019/9/11 15:34, Michal Hocko wrote:
> On Wed 11-09-19 15:22:30, Yunsheng Lin wrote:
> [...]
>> It seems that there is no protection that prevent setting the node
>> of device to an invalid node.
>> And the kernel does have a few different check now:
>> 1) some does " < 0" check;
>> 2) some
On Wed 11-09-19 15:22:30, Yunsheng Lin wrote:
[...]
> It seems that there is no protection that prevent setting the node
> of device to an invalid node.
> And the kernel does have a few different check now:
> 1) some does " < 0" check;
> 2) some does "== NUMA_NO_NODE" check;
> 3) some does ">=
On 2019/9/11 14:49, Michal Hocko wrote:
> On Wed 11-09-19 14:15:51, Yunsheng Lin wrote:
>> On 2019/9/11 13:33, Michal Hocko wrote:
>>> On Tue 10-09-19 14:53:39, Michal Hocko wrote:
On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> On 2019/9/10 19:12, Greg KH wrote:
>> On Tue, Sep 10,
On Wed 11-09-19 14:15:51, Yunsheng Lin wrote:
> On 2019/9/11 13:33, Michal Hocko wrote:
> > On Tue 10-09-19 14:53:39, Michal Hocko wrote:
> >> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> >>> On 2019/9/10 19:12, Greg KH wrote:
> On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
On 2019/9/11 13:33, Michal Hocko wrote:
> On Tue 10-09-19 14:53:39, Michal Hocko wrote:
>> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
>>> On 2019/9/10 19:12, Greg KH wrote:
On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
On Tue 10-09-19 14:53:39, Michal Hocko wrote:
> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> > On 2019/9/10 19:12, Greg KH wrote:
> > > On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> > >> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> > >>> On 2019/9/10 17:31, Greg KH wrote:
>
On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> On 2019/9/10 19:12, Greg KH wrote:
> > On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> >> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> >>> On 2019/9/10 17:31, Greg KH wrote:
> On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng
On 2019/9/10 19:12, Greg KH wrote:
> On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
>> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
>>> On 2019/9/10 17:31, Greg KH wrote:
On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> On 2019/9/9 17:53, Greg KH wrote:
On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> > On 2019/9/10 17:31, Greg KH wrote:
> > > On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> > >> On 2019/9/9 17:53, Greg KH wrote:
> > >>> On Mon, Sep 09, 2019 at
On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> On 2019/9/10 17:31, Greg KH wrote:
> > On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> >> On 2019/9/9 17:53, Greg KH wrote:
> >>> On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
> Currently a device does not belong
On Tue 10-09-19 18:40:12, Yunsheng Lin wrote:
> On 2019/9/10 15:24, Michal Hocko wrote:
> > Our emails crossed, sorry about that.
> >
> > On Tue 10-09-19 15:08:20, Yunsheng Lin wrote:
> >> On 2019/9/10 2:50, Michal Hocko wrote:
> >>> On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
> > [...]
>
On 2019/9/10 17:31, Greg KH wrote:
> On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
>> On 2019/9/9 17:53, Greg KH wrote:
>>> On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
Currently a device does not belong to any of the numa nodes
(dev->numa_node is
On 2019/9/10 15:24, Michal Hocko wrote:
> Our emails crossed, sorry about that.
>
> On Tue 10-09-19 15:08:20, Yunsheng Lin wrote:
>> On 2019/9/10 2:50, Michal Hocko wrote:
>>> On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
> [...]
Even if a device's numa node is not specified, the device
On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> On 2019/9/9 17:53, Greg KH wrote:
> > On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
> >> Currently a device does not belong to any of the numa nodes
> >> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
>
Our emails crossed, sorry about that.
On Tue 10-09-19 15:08:20, Yunsheng Lin wrote:
> On 2019/9/10 2:50, Michal Hocko wrote:
> > On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
[...]
> >> Even if a device's numa node is not specified, the device really
> >> does belong to a node.
> >
> > What does
On Tue 10-09-19 14:43:32, Yunsheng Lin wrote:
> On 2019/9/9 17:53, Greg KH wrote:
[...]
> > But as we do not know the node, can we cause more harm by randomly
> > picking one (i.e. putting it all in node 0)?
> If we do not pick node 0 for device with invalid node, then caller need
> to check the
On 2019/9/10 2:50, Michal Hocko wrote:
> On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
>> Currently a device does not belong to any of the numa nodes
>> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
>> specified by fw nor by virtual device layer and the device has
>> no parent
On 2019/9/9 17:53, Greg KH wrote:
> On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
>> Currently a device does not belong to any of the numa nodes
>> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
>> specified by fw nor by virtual device layer and the device has
>> no
On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
> Currently a device does not belong to any of the numa nodes
> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
> specified by fw nor by virtual device layer and the device has
> no parent device.
>
> According to discussion in [1]:
On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
> Currently a device does not belong to any of the numa nodes
> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
> specified by fw nor by virtual device layer and the device has
> no parent device.
Is this really a problem?
Currently a device does not belong to any of the numa nodes
(dev->numa_node is NUMA_NO_NODE) when the node id is neither
specified by fw nor by virtual device layer and the device has
no parent device.
According to discussion in [1]:
Even if a device's numa node is not specified, the device
24 matches
Mail list logo
