linux-kernel - [tip:sched/core] sched/numa: Init numa balancing fields of init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <tip-d8b163c4c657478ef33c082cff78d03a4ca07bb2@git.kernel.org>
Date:	Sun, 16 Nov 2014 04:33:35 -0800
From:	tip-bot for Kirill Tkhai <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	paulmck@...ux.vnet.ibm.com, eparis@...hat.com, oleg@...hat.com,
	hpa@...or.com, ktkhai@...allels.com, dserrg@...il.com,
	peterz@...radead.org, tglx@...utronix.de, mingo@...nel.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: [tip:sched/core] sched/numa:
  Init numa balancing fields of init_task

Commit-ID:  d8b163c4c657478ef33c082cff78d03a4ca07bb2
Gitweb:     http://git.kernel.org/tip/d8b163c4c657478ef33c082cff78d03a4ca07bb2
Author:     Kirill Tkhai <ktkhai@...allels.com>
AuthorDate: Tue, 11 Nov 2014 12:46:29 +0300
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Sun, 16 Nov 2014 10:59:01 +0100

sched/numa: Init numa balancing fields of init_task

We do not initialize init_task.numa_preferred_nid,
but this value is inherited by userspace "init"
process:

rest_init()->kernel_thread(kernel_init)->do_fork(CLONE_VM);

__sched_fork()
{
	if (clone_flags & CLONE_VM)
		p->numa_preferred_nid = current->numa_preferred_nid;
	else
		p->numa_preferred_nid = -1;
}

kernel_init() becomes userspace "init" process.

So, we propagate garbage nid to userspace, and it may be used
during numa balancing.

Currently, we do not have reports about this brings a problem,
but it seem we should set it for sure.

Even if init_task.numa_preferred_nid is zero, we may meet a weird
configuration without nid#0. On sparc64, where processors are
numbered physically, I saw a machine without cpu#1, while cpu#2
existed. Possible, something similar may be with numa nodes.
So, let's initialize it and be sure we're safe.

Signed-off-by: Kirill Tkhai <ktkhai@...allels.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Cc: Eric Paris <eparis@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Sergey Dyasly <dserrg@...il.com>
Link: http://lkml.kernel.org/r/1415699189.15631.6.camel@tkhai
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 include/linux/init_task.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 77fc43f..5f30ac8 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -166,6 +166,15 @@ extern struct task_group root_task_group;
 # define INIT_RT_MUTEXES(tsk)
 #endif
 
+#ifdef CONFIG_NUMA_BALANCING
+# define INIT_NUMA_BALANCING(tsk)					\
+	.numa_preferred_nid = -1,					\
+	.numa_group = NULL,						\
+	.numa_faults = NULL,
+#else
+# define INIT_NUMA_BALANCING(tsk)
+#endif
+
 /*
  *  INIT_TASK is used to set up the first task table, touch at
  * your own risk!. Base=0, limit=0x1fffff (=2MB)
@@ -237,6 +246,7 @@ extern struct task_group root_task_group;
 	INIT_CPUSET_SEQ(tsk)						\
 	INIT_RT_MUTEXES(tsk)						\
 	INIT_VTIME(tsk)							\
+	INIT_NUMA_BALANCING(tsk)					\
 }
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/