1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Delivered-To: jwboyer@gmail.com
Received: by 10.76.27.197 with SMTP id v5csp13792oag;
Tue, 28 Jan 2014 01:18:26 -0800 (PST)
X-Received: by 10.68.203.102 with SMTP id kp6mr520665pbc.14.1390900706562;
Tue, 28 Jan 2014 01:18:26 -0800 (PST)
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
by mx.google.com with ESMTP id fl7si14540600pad.345.2014.01.28.01.17.52
for <multiple recipients>;
Tue, 28 Jan 2014 01:18:26 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1754809AbaA1JD6 (ORCPT <rfc822;gardner.ben.linux@gmail.com>
+ 99 others); Tue, 28 Jan 2014 04:03:58 -0500
Received: from cn.fujitsu.com ([222.73.24.84]:28048 "EHLO song.cn.fujitsu.com"
rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP
id S1750931AbaA1JCt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
Tue, 28 Jan 2014 04:02:49 -0500
X-IronPort-AV: E=Sophos;i="4.95,735,1384272000";
d="scan'208";a="9461135"
Received: from unknown (HELO tang.cn.fujitsu.com) ([10.167.250.3])
by song.cn.fujitsu.com with ESMTP; 28 Jan 2014 16:59:02 +0800
Received: from fnstmail02.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1])
by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id s0S92ilu031286;
Tue, 28 Jan 2014 17:02:45 +0800
Received: from G08FNSTD090432.fnst.cn.fujitsu.com ([10.167.226.99])
by fnstmail02.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.3)
with ESMTP id 2014012817011055-1418712 ;
Tue, 28 Jan 2014 17:01:10 +0800
From: Tang Chen <tangchen@cn.fujitsu.com>
To: davej@redhat.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, akpm@linux-foundation.org,
zhangyanfei@cn.fujitsu.com, guz.fnst@cn.fujitsu.com
Cc: x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when synchronizing nid to memblock.reserved.
Date: Tue, 28 Jan 2014 17:05:16 +0800
Message-Id: <1390899916-23566-3-git-send-email-tangchen@cn.fujitsu.com>
X-Mailer: git-send-email 1.7.11.7
In-Reply-To: <1390899916-23566-1-git-send-email-tangchen@cn.fujitsu.com>
References: <1390899916-23566-1-git-send-email-tangchen@cn.fujitsu.com>
X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.3|September 15, 2011) at
2014/01/28 17:01:10,
Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at
2014/01/28 17:01:11,
Serialize complete at 2014/01/28 17:01:11
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
The following path will cause array out of bound.
memblock_add_region() will always set nid in memblock.reserved to MAX_NUMNODES.
In numa_register_memblks(), after we set all nid to correct valus in memblock.reserved,
we called setup_node_data(), and used memblock_alloc_nid() to allocate memory, with
nid set to MAX_NUMNODES.
The nodemask_t type can be seen as a bit array. And the index is 0 ~ MAX_NUMNODES-1.
After that, when we call node_set() in numa_clear_kernel_node_hotplug(), the nodemask_t
got an index of value MAX_NUMNODES, which is out of [0 ~ MAX_NUMNODES-1].
See below:
numa_init()
|---> numa_register_memblks()
| |---> memblock_set_node(memory) set correct nid in memblock.memory
| |---> memblock_set_node(reserved) set correct nid in memblock.reserved
| |......
| |---> setup_node_data()
| |---> memblock_alloc_nid() here, nid is set to MAX_NUMNODES (1024)
|......
|---> numa_clear_kernel_node_hotplug()
|---> node_set() here, we have an index 1024, and overflowed
This patch moves nid setting to numa_clear_kernel_node_hotplug() to fix this problem.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Tested-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
---
arch/x86/mm/numa.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 00c9f09..a183b43 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -493,14 +493,6 @@ static int __init numa_register_memblks(struct numa_meminfo *mi)
struct numa_memblk *mb = &mi->blk[i];
memblock_set_node(mb->start, mb->end - mb->start,
&memblock.memory, mb->nid);
-
- /*
- * At this time, all memory regions reserved by memblock are
- * used by the kernel. Set the nid in memblock.reserved will
- * mark out all the nodes the kernel resides in.
- */
- memblock_set_node(mb->start, mb->end - mb->start,
- &memblock.reserved, mb->nid);
}
/*
@@ -571,6 +563,17 @@ static void __init numa_clear_kernel_node_hotplug(void)
nodes_clear(numa_kernel_nodes);
+ /*
+ * At this time, all memory regions reserved by memblock are
+ * used by the kernel. Set the nid in memblock.reserved will
+ * mark out all the nodes the kernel resides in.
+ */
+ for (i = 0; i < numa_meminfo.nr_blks; i++) {
+ struct numa_memblk *mb = &numa_meminfo.blk[i];
+ memblock_set_node(mb->start, mb->end - mb->start,
+ &memblock.reserved, mb->nid);
+ }
+
/* Mark all kernel nodes. */
for (i = 0; i < type->cnt; i++)
node_set(type->regions[i].nid, numa_kernel_nodes);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
