mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Shreyas B. Prabhu" <shreyas@linux.vnet.ibm.com>
To: akpm@linux-foundation.org, rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org, preeti@linux.vnet.ibm.com,
	paulmck@linux.vnet.ibm.com, mingo@redhat.com,
	"Shreyas B. Prabhu" <shreyas@linux.vnet.ibm.com>
Subject: [PATCH linux-next] tracing/mm: Use raw_smp_processor_id() instead of smp_processor_id()
Date: Fri, 15 May 2015 18:57:41 +0530	[thread overview]
Message-ID: <1431696461-9683-1-git-send-email-shreyas@linux.vnet.ibm.com> (raw)

trace_mm_page_pcpu_drain, trace_kmem_cache_free, trace_mm_page_free
can be potentially called from an offlined cpu. Since trace points use
RCU and RCU should not be used from offlined cpus, we have checks to
filter out such calls.

But these checks use smp_processor_id() and since these trace calls can
happen from preemptable sections, this throws a warning when running
with CONFIG_DEBUG_PREEMPT set.

Now consider task gets migrated after calling smp_processor_id()
 - From an online cpu to another online cpu - No impact
 - From an online cpu to an offline cpu - Should never happen
 - From an offline cpu to an online cpu - Once a cpu has been
   offlined it returns to cpu_idle_loop, discovers its offline and calls
   arch_cpu_idle_dead. All this happens with preemption disabled. So
   this scenario too should never happen.

Thus running with PREEMPT set has no impact on the condition. So use
raw_smp_processor_id() so that the warnings are suppressed.

Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
---
 include/trace/events/kmem.h | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index 6cd975f..f7554fd 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -146,7 +146,16 @@ DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
 
 	TP_ARGS(call_site, ptr),
 
-	TP_CONDITION(cpu_online(smp_processor_id()))
+	/*
+	 * This trace can be potentially called from an offlined cpu.
+	 * Since trace points use RCU and RCU should not be used from
+	 * offline cpus, filter such calls out.
+	 * While this trace can be called from a preemptable section,
+	 * it has no impact on the condition since tasks can migrate
+	 * only from online cpus to other online cpus. Thus its safe
+	 * to use raw_smp_processor_id.
+	 */
+	TP_CONDITION(cpu_online(raw_smp_processor_id()))
 );
 
 TRACE_EVENT_CONDITION(mm_page_free,
@@ -155,7 +164,17 @@ TRACE_EVENT_CONDITION(mm_page_free,
 
 	TP_ARGS(page, order),
 
-	TP_CONDITION(cpu_online(smp_processor_id())),
+
+	/*
+	 * This trace can be potentially called from an offlined cpu.
+	 * Since trace points use RCU and RCU should not be used from
+	 * offline cpus, filter such calls out.
+	 * While this trace can be called from a preemptable section,
+	 * it has no impact on the condition since tasks can migrate
+	 * only from online cpus to other online cpus. Thus its safe
+	 * to use raw_smp_processor_id.
+	 */
+	TP_CONDITION(cpu_online(raw_smp_processor_id())),
 
 	TP_STRUCT__entry(
 		__field(	unsigned long,	pfn		)
@@ -263,7 +282,16 @@ TRACE_EVENT_CONDITION(mm_page_pcpu_drain,
 
 	TP_ARGS(page, order, migratetype),
 
-	TP_CONDITION(cpu_online(smp_processor_id())),
+	/*
+	 * This trace can be potentially called from an offlined cpu.
+	 * Since trace points use RCU and RCU should not be used from
+	 * offline cpus, filter such calls out.
+	 * While this trace can be called from a preemptable section,
+	 * it has no impact on the condition since tasks can migrate
+	 * only from online cpus to other online cpus. Thus its safe
+	 * to use raw_smp_processor_id.
+	 */
+	TP_CONDITION(cpu_online(raw_smp_processor_id())),
 
 	TP_STRUCT__entry(
 		__field(	unsigned long,	pfn		)
-- 
1.9.3


             reply	other threads:[~2015-05-15 13:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15 13:27 Shreyas B. Prabhu [this message]
2015-05-15 13:32 ` Preeti U Murthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1431696461-9683-1-git-send-email-shreyas@linux.vnet.ibm.com \
    --to=shreyas@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®