From: Yunsheng Lin <linyunsheng@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <rafael@kernel.org>, <linux-kernel@vger.kernel.org>,
<peterz@infradead.org>, <mingo@kernel.org>, <mhocko@kernel.org>,
<linuxarm@huawei.com>
Subject: Re: [PATCH] driver core: ensure a device has valid node id in device_add()
Date: Tue, 10 Sep 2019 18:58:05 +0800 [thread overview]
Message-ID: <34feca56-c95e-41a6-e09f-8fc2d2fd2bce@huawei.com> (raw)
In-Reply-To: <20190910093114.GA19821@kroah.com>
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
>
> .
>
next prev parent reply other threads:[~2019-09-10 10:59 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 [this message]
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
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=34feca56-c95e-41a6-e09f-8fc2d2fd2bce@huawei.com \
--to=linyunsheng@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).