linux-kernel - [PATCH v2 2/2] tracing: Avoid isolated CPUs when queueing fsnotify irqwork

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]

Message-Id: <20220301113053.141514-2-nsaenzju@redhat.com>
Date:   Tue,  1 Mar 2022 12:30:53 +0100
From:   Nicolas Saenz Julienne <nsaenzju@...hat.com>
To:     mingo@...hat.com, peterz@...radead.org, frederic@...nel.org,
        rostedt@...dmis.org
Cc:     tglx@...utronix.de, mtosatti@...hat.com, bristot@...hat.com,
        linux-kernel@...r.kernel.org,
        Nicolas Saenz Julienne <nsaenzju@...hat.com>
Subject: [PATCH v2 2/2] tracing: Avoid isolated CPUs when queueing fsnotify irqwork

There isn't any need for this irq_work to be run locally, so avoid doing
so when the CPU is isolated.

Note that this is especially bad as queueing it into a local isolated
CPU might add noise to what was meant to be traced in the first place.

Signed-off-by: Nicolas Saenz Julienne <nsaenzju@...hat.com>
---

Changes since v1:
 - Rebase to cater for:
     04d4e665a609 ("sched/isolation: Use single feature type while
     referring to housekeeping cpumask")

 kernel/trace/trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index bb2caf6aac01..250603b4eb3e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -12,6 +12,7 @@
  *  Copyright (C) 2004-2006 Ingo Molnar
  *  Copyright (C) 2004 Nadia Yvette Chambers
  */
+#include <linux/sched/isolation.h>
 #include <linux/ring_buffer.h>
 #include <generated/utsrelease.h>
 #include <linux/stacktrace.h>
@@ -1726,7 +1727,7 @@ void latency_fsnotify(struct trace_array *tr)
 	 * possible that we are called from __schedule() or do_idle(), which
 	 * could cause a deadlock.
 	 */
-	irq_work_queue(&tr->fsnotify_irqwork);
+	irq_work_queue_on(&tr->fsnotify_irqwork, housekeeping_any_cpu(HK_TYPE_MISC));
 }
 
 #elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)	\
-- 
2.35.1