Re: [PATCH] driver core: ensure a device has valid node id in device_add()
From: Yunsheng Lin
Date: Tue Sep 10 2019 - 07:00:12 EST
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 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?
>>
>> Not really.
>> Someone need to guess the node id when it is not specified, right?
>
> No, why? Guessing guarantees you will get it wrong on some systems.
>
> Are you seeing real problems because the id is not being set? What
> problem is this fixing that you can actually observe?
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:
there are different checking to return value of dev_to_node(), I though
it is better to consistently do checking in cpumask_of_node(), then
discussion [1] [2] led to do the checking in device_add().
[ 42.970381] ==================================================================
[ 42.977595] BUG: KASAN: global-out-of-bounds in __bitmap_weight+0x48/0xb0
[ 42.984370] Read of size 8 at addr ffff20008cdf8790 by task kworker/0:1/13
[ 42.991230]
[ 42.992712] CPU: 0 PID: 13 Comm: kworker/0:1 Tainted: G O 5.2.0-rc4-g8bde06a-dirty #3
[ 43.001830] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B050.01 08/08/2019
[ 43.011298] Workqueue: events work_for_cpu_fn
[ 43.015643] Call trace:
[ 43.018078] dump_backtrace+0x0/0x1e8
[ 43.021727] show_stack+0x14/0x20
[ 43.025031] dump_stack+0xc4/0xfc
[ 43.028335] print_address_description+0x178/0x270
[ 43.033113] __kasan_report+0x164/0x1b8
[ 43.036936] kasan_report+0xc/0x18
[ 43.040325] __asan_load8+0x84/0xa8
[ 43.043801] __bitmap_weight+0x48/0xb0
[ 43.047552] hclge_init_ae_dev+0x988/0x1e78 [hclge]
[ 43.052418] hnae3_register_ae_dev+0xcc/0x278 [hnae3]
[ 43.057467] hns3_probe+0xe0/0x120 [hns3]
[ 43.061464] local_pci_probe+0x74/0xf0
[ 43.065200] work_for_cpu_fn+0x2c/0x48
[ 43.068937] process_one_work+0x3c0/0x878
[ 43.072934] worker_thread+0x400/0x670
[ 43.076670] kthread+0x1b0/0x1b8
[ 43.079885] ret_from_fork+0x10/0x18
[ 43.083446]
[ 43.084925] The buggy address belongs to the variable:
[ 43.090052] numa_distance+0x30/0x40
[ 43.093613]
[ 43.095091] Memory state around the buggy address:
[ 43.099870] ffff20008cdf8680: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 fa fa
[ 43.107078] ffff20008cdf8700: fa fa fa fa 04 fa fa fa fa fa fa fa 00 fa fa fa
[ 43.114286] >ffff20008cdf8780: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
[ 43.121494] ^
[ 43.125230] ffff20008cdf8800: 01 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[ 43.132439] ffff20008cdf8880: fa fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[ 43.139646] ==================================================================
[1] https://lore.kernel.org/patchwork/patch/1122081/
[2] https://lore.kernel.org/patchwork/patch/1122516/
>
> thanks,
>
> greg k-h
>
> .
>