linux-kernel - [GIT PULL][PATCH] tracing: Fix hwlat kthread migration

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

Date:   Tue, 31 Jan 2017 16:26:55 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: [GIT PULL][PATCH] tracing: Fix hwlat kthread migration


Linus,

It was reported to me that the thread created by the hwlat tracer does
not migrate after the first instance. I found that there was a small
bug in the logic, and fixed it. It's minor, but should be fixed regardless.
There's not much impact outside the hwlat tracer.


Please pull the latest trace-4.10-rc2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-4.10-rc2

Tag SHA1: c3330f7b334f77118861ed8e864d82d217aa5efd
Head SHA1: 79c6f448c8b79c321e4a1f31f98194e4f6b6cae7


Steven Rostedt (VMware) (1):
      tracing: Fix hwlat kthread migration

----
 kernel/trace/trace_hwlat.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
---------------------------
commit 79c6f448c8b79c321e4a1f31f98194e4f6b6cae7
Author: Steven Rostedt (VMware) <rostedt@...dmis.org>
Date:   Mon Jan 30 19:27:10 2017 -0500

    tracing: Fix hwlat kthread migration
    
    The hwlat tracer creates a kernel thread at start of the tracer. It is
    pinned to a single CPU and will move to the next CPU after each period of
    running. If the user modifies the migration thread's affinity, it will not
    change after that happens.
    
    The original code created the thread at the first instance it was called,
    but later was changed to destroy the thread after the tracer was finished,
    and would not be created until the next instance of the tracer was
    established. The code that initialized the affinity was only called on the
    initial instantiation of the tracer. After that, it was not initialized, and
    the previous affinity did not match the current newly created one, making
    it appear that the user modified the thread's affinity when it did not, and
    the thread failed to migrate again.
    
    Cc: stable@...r.kernel.org
    Fixes: 0330f7aa8ee6 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c
index 775569ec50d0..af344a1bf0d0 100644
--- a/kernel/trace/trace_hwlat.c
+++ b/kernel/trace/trace_hwlat.c
@@ -266,7 +266,7 @@ static int get_sample(void)
 static struct cpumask save_cpumask;
 static bool disable_migrate;
 
-static void move_to_next_cpu(void)
+static void move_to_next_cpu(bool initmask)
 {
 	static struct cpumask *current_mask;
 	int next_cpu;
@@ -275,7 +275,7 @@ static void move_to_next_cpu(void)
 		return;
 
 	/* Just pick the first CPU on first iteration */
-	if (!current_mask) {
+	if (initmask) {
 		current_mask = &save_cpumask;
 		get_online_cpus();
 		cpumask_and(current_mask, cpu_online_mask, tracing_buffer_mask);
@@ -330,10 +330,12 @@ static void move_to_next_cpu(void)
 static int kthread_fn(void *data)
 {
 	u64 interval;
+	bool initmask = true;
 
 	while (!kthread_should_stop()) {
 
-		move_to_next_cpu();
+		move_to_next_cpu(initmask);
+		initmask = false;
 
 		local_irq_disable();
 		get_sample();