From: Yunsheng Lin <linyunsheng@huawei.com>
To: <catalin.marinas@arm.com>, <will@kernel.org>, <mingo@redhat.com>,
<bp@alien8.de>, <rth@twiddle.net>, <ink@jurassic.park.msu.ru>,
<mattst88@gmail.com>, <benh@kernel.crashing.org>,
<paulus@samba.org>, <mpe@ellerman.id.au>,
<heiko.carstens@de.ibm.com>, <gor@linux.ibm.com>,
<borntraeger@de.ibm.com>, <ysato@users.sourceforge.jp>,
<dalias@libc.org>, <davem@davemloft.net>, <ralf@linux-mips.org>,
<paul.burton@mips.com>, <jhogan@kernel.org>,
<jiaxun.yang@flygoat.com>, <chenhc@lemote.com>
Cc: <akpm@linux-foundation.org>, <rppt@linux.ibm.com>,
<anshuman.khandual@arm.com>, <tglx@linutronix.de>, <cai@lca.pw>,
<robin.murphy@arm.com>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <hpa@zytor.com>, <x86@kernel.org>,
<dave.hansen@linux.intel.com>, <luto@kernel.org>,
<peterz@infradead.org>, <len.brown@intel.com>, <axboe@kernel.dk>,
<dledford@redhat.com>, <jeffrey.t.kirsher@intel.com>,
<linux-alpha@vger.kernel.org>, <naveen.n.rao@linux.vnet.ibm.com>,
<mwb@linux.vnet.ibm.com>, <linuxppc-dev@lists.ozlabs.org>,
<linux-s390@vger.kernel.org>, <linux-sh@vger.kernel.org>,
<sparclinux@vger.kernel.org>, <tbogendoerfer@suse.de>,
<linux-mips@vger.kernel.org>, <rafael@kernel.org>,
<mhocko@kernel.org>, <gregkh@linuxfoundation.org>
Subject: [PATCH v3 0/8] make node_to_cpumask_map() NUMA_NO_NODE aware
Date: Thu, 12 Sep 2019 18:15:26 +0800 [thread overview]
Message-ID: <1568283334-178380-1-git-send-email-linyunsheng@huawei.com> (raw)
When passing the return value of dev_to_node() to cpumask_of_node()
without checking the node id if the node id is NUMA_NO_NODE, there is
global-out-of-bounds detected by KASAN:
[ 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] ==================================================================
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.
Note:
1. Only arm64 has been compile tested and tested on real board.
2. x86 has been compile tested with defconfig.
3. Other arch has not been compile tested or tested on real board.
Change log:
V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask
for NUMA_NO_NODE case, and change the commit log to better justify
the change, drop sh arch change since it always return cpu_online_mask.
Yunsheng Lin (8):
arm64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for arm64
x86: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for x86
alpha: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for alpha
powerpc: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for
powerpc
s390: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for s390
sparc64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for
sparc64
mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips
mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for
loongson64
arch/alpha/include/asm/topology.h | 2 +-
arch/arm64/include/asm/numa.h | 3 +++
arch/arm64/mm/numa.c | 5 ++++-
arch/mips/include/asm/mach-ip27/topology.h | 4 ++--
arch/mips/include/asm/mach-loongson64/topology.h | 4 +++-
arch/powerpc/include/asm/topology.h | 4 ++--
arch/s390/include/asm/topology.h | 3 +++
arch/sparc/include/asm/topology_64.h | 4 ++--
arch/x86/include/asm/topology.h | 3 +++
arch/x86/mm/numa.c | 7 +++++--
10 files changed, 28 insertions(+), 11 deletions(-)
--
2.8.1
next reply other threads:[~2019-09-12 10:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 10:15 Yunsheng Lin [this message]
2019-09-12 10:15 ` [PATCH v3 1/8] arm64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for arm64 Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 2/8] x86: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for x86 Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 3/8] alpha: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for alpha Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 4/8] powerpc: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for powerpc Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 5/8] s390: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for s390 Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 6/8] sparc64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for sparc64 Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips Yunsheng Lin
2019-09-15 5:49 ` Mike Rapoport
2019-09-15 6:13 ` Yunsheng Lin
2019-09-15 6:46 ` Mike Rapoport
2019-09-15 6:51 ` Yunsheng Lin
2019-09-12 10:15 ` [PATCH v3 8/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for loongson64 Yunsheng Lin
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=1568283334-178380-1-git-send-email-linyunsheng@huawei.com \
--to=linyunsheng@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=axboe@kernel.dk \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=cai@lca.pw \
--cc=catalin.marinas@arm.com \
--cc=chenhc@lemote.com \
--cc=dalias@libc.org \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=gor@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jhogan@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=len.brown@intel.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mattst88@gmail.com \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=mwb@linux.vnet.ibm.com \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=paul.burton@mips.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=ralf@linux-mips.org \
--cc=robin.murphy@arm.com \
--cc=rppt@linux.ibm.com \
--cc=rth@twiddle.net \
--cc=sparclinux@vger.kernel.org \
--cc=tbogendoerfer@suse.de \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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
all inboxes | Powered by JetHome®