Fix a memory overrun when using -p with a single pid on a machine
with non-consecutive NUMA nodes, due to the node number being used
instead of the node index.
Correct this by adding a function to find the index of a node number
by searching through the node indices list.
Signed-off-by: Sam Bobroff <sam.bobroff@xxxxxxxxxxx>
---
Hi,
I've found that "numastat -p <pid>" segfaults on machines that have
non-consecutive NUMA nodes. The machine I discovered it on had two
nodes, 0 and 8.
Here's a patch that fixes the problem for me. I'm not sure if this is
the best fix, particularly the linear search over nodes, but maybe
it's OK. It does at least explain what I think is happening.
Cheers,
Sam.
numastat.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/numastat.c b/numastat.c
index 1924dba..e5eebd7 100644
--- a/numastat.c
+++ b/numastat.c
@@ -933,6 +933,17 @@ void show_system_info() {
}
+int node_num_to_ix(int node_num) {
+ for (int node_ix = 0; (node_ix < num_nodes); node_ix++) {
+ if (node_ix_map[node_ix] == node_num) {
+ return node_ix;
+ }
+ }
+ perror("unknown node in numa map");
+ exit(EXIT_FAILURE);
+}
+
+
void show_process_info() {
vtab_t table;
int header_rows = 2;
@@ -1035,7 +1046,7 @@ void show_process_info() {
// node number and accumulate the number of pages in the specific
// category (and also add to the total).
if (p[0] == 'N') {
- int node_num = (int)strtol(&p[1], &p, 10);
+ int node_ix = node_num_to_ix((int)strtol(&p[1], &p, 10));
if (p[0] != '=') {
perror("node value parse error");
exit(EXIT_FAILURE);
@@ -1054,7 +1065,7 @@ void show_process_info() {
} else {
tmp_row = header_rows + pid_ix;
}
- int tmp_col = header_cols + node_num;
+ int tmp_col = header_cols + node_ix;
double_addto(&table, tmp_row, tmp_col, value);
double_addto(&table, tmp_row, total_col_ix, value);
double_addto(&table, total_row_ix, tmp_col, value);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
