linux-kernel - Re: [RFC] kthread_create_on_node is failing to honor the node choice

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Jul 2015 15:12:59 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nathan Zimmer <nzimmer@....com>
Cc:	Nishanth Aravamudan <nacc@...ux.vnet.ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC] kthread_create_on_node is failing to honor the node
 choice

On Thu, 25 Jun 2015 16:44:13 -0500 Nathan Zimmer <nzimmer@....com> wrote:

> In kthread_create_on_node we set_cpus_allowed to cpu_all_mask
> regardless of what the node is requested.
> This seems incorrect.

The `node' arg to kthread_create_on_node() refers to which node the
task_struct and thread_info are allocated from.  It doesn't refer to
the CPUs upon which the thread is executed.  See
kthread_create_info.node and that gruesome task_struct.pref_node_fork
thing.

The kthread_create_on_node() kerneldoc explains this, in a confused
way.  It needs a s/-1/NUMA_NO_NODE/.

I'm a bit surprised that kthread_create_on_node() futzes with the new
thread's policy and cpumask after it has been created.  Wouldn't it be
simpler/faster to have the thread itself set these things while it's
starting up?

As to whether kthread_create_on_node() should bind the thread to that
node's CPUs: unclear. 
drivers/thermal/intel_powerclamp.c:start_power_clamp() understands how
kthread_create_on_node() works.  I guess the code is OK as-is, but the
documentation could be improved.  Perfunctory effort:

--- a/kernel/kthread.c~a
+++ a/kernel/kthread.c
@@ -246,7 +246,7 @@ static void create_kthread(struct kthrea
  * kthread_create_on_node - create a kthread.
  * @threadfn: the function to run until signal_pending(current).
  * @data: data ptr for @threadfn.
- * @node: memory node number.
+ * @node: task and thread structures for the thread are allocated on this node
  * @namefmt: printf-style name for the thread.
  *
  * Description: This helper function creates and names a kernel
@@ -254,7 +254,7 @@ static void create_kthread(struct kthrea
  * it.  See also kthread_run().
  *
  * If thread is going to be bound on a particular cpu, give its node
- * in @node, to get NUMA affinity for kthread stack, or else give -1.
+ * in @node, to get NUMA affinity for kthread stack, or else give NUMA_NO_NODE.
  * When woken, the thread will run @threadfn() with @data as its
  * argument. @threadfn() can either call do_exit() directly if it is a
  * standalone thread for which no one will call kthread_stop(), or
_

--
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/