All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Joel Fernandes <joelaf@google.com>,
	linux-kernel@vger.kernel.org,
	Peter Zilstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Tom Zanussi <tom.zanussi@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Glexiner <tglx@linutronix.de>,
	Boqun Feng <boqun.feng@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Fenguang Wu <fengguang.wu@intel.com>,
	Baohong Liu <baohong.liu@intel.com>,
	Vedang Patel <vedang.patel@intel.com>,
	kernel-team@android.com
Subject: Re: [PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on
Date: Fri, 27 Apr 2018 09:44:16 -0700	[thread overview]
Message-ID: <20180427164416.GN26088@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180427121330.40b7ef15@gandalf.local.home>

On Fri, Apr 27, 2018 at 12:13:30PM -0400, Steven Rostedt wrote:
> On Fri, 27 Apr 2018 08:57:01 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > > +		if (preempt_on) {					\
> > > +			WARN_ON_ONCE(in_nmi()); /* no srcu from nmi */	\  
> > 
> > Very good on this check, thank you!
> 
> I think you need to return and not call the read lock.

Works for me either way, at least assuming that the splat actually gets
printed.  ;-)

> 			if (WARN_ON_ONCE(in_nmi()))
> 				return;
> 
> > 
> > > +			idx = srcu_read_lock(&tracepoint_srcu);         \  
> > 
> > Hmmm...  Do I need to create a _notrace variant of srcu_read_lock()
> > and srcu_read_unlock()?
> 
> I think so.

OK, please see the (untested) patch below.  Of course,
srcu_read_lock_notrace() invokes __srcu_read_lock(), which looks as
follows:

	int __srcu_read_lock(struct srcu_struct *sp)
	{
		int idx;

		idx = READ_ONCE(sp->srcu_idx) & 0x1;
		this_cpu_inc(sp->sda->srcu_lock_count[idx]);
		smp_mb(); /* B */  /* Avoid leaking the critical section. */
		return idx;
	}

Do I also need to make a notrace version of __srcu_read_lock()?
Same question for __srcu_read_unlock(), which is similar.  If so,
assuming that there is no need for a notrace variant of this_cpu_inc()
and smp_mb(), I suppose I could simply macro-ize the internals in both
cases, but perhaps you have a better approach.

								Thanx, Paul

------------------------------------------------------------------------

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 91494d7e8e41..e2e2cf05a6eb 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -195,6 +195,16 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp)
 	return retval;
 }
 
+/* Used by tracing, cannot be traced and cannot invoke lockdep. */
+static inline notrace int
+srcu_read_lock_notrace(struct srcu_struct *sp) __acquires(sp)
+{
+	int retval;
+
+	retval = __srcu_read_lock(sp);
+	return retval;
+}
+
 /**
  * srcu_read_unlock - unregister a old reader from an SRCU-protected structure.
  * @sp: srcu_struct in which to unregister the old reader.
@@ -205,6 +215,13 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp)
 static inline void srcu_read_unlock(struct srcu_struct *sp, int idx)
 	__releases(sp)
 {
+	__srcu_read_unlock(sp, idx);
+}
+
+/* Used by tracing, cannot be traced and cannot call lockdep. */
+static inline notrace void
+srcu_read_unlock_notrace(struct srcu_struct *sp, int idx) __releases(sp)
+{
 	rcu_lock_release(&(sp)->dep_map);
 	__srcu_read_unlock(sp, idx);
 }

  parent reply	other threads:[~2018-04-27 16:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27  4:26 [PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on Joel Fernandes
2018-04-27 14:26 ` Mathieu Desnoyers
2018-04-27 14:47   ` Steven Rostedt
2018-04-27 15:38     ` Paul E. McKenney
2018-04-27 15:40       ` Steven Rostedt
2018-04-27 15:43         ` Mathieu Desnoyers
2018-04-27 16:08           ` Steven Rostedt
2018-04-27 15:58         ` Paul E. McKenney
2018-04-27 15:42     ` Mathieu Desnoyers
2018-04-27 16:07       ` Steven Rostedt
2018-04-27 16:30     ` Joel Fernandes
2018-04-27 16:37       ` Steven Rostedt
2018-04-27 18:11         ` Joel Fernandes
2018-04-27 18:42           ` Mathieu Desnoyers
2018-04-27 15:57 ` Paul E. McKenney
2018-04-27 16:13   ` Steven Rostedt
2018-04-27 16:22     ` Joel Fernandes
2018-04-27 16:44     ` Paul E. McKenney [this message]
2018-04-27 16:14   ` Joel Fernandes
2018-04-27 16:22     ` Steven Rostedt
2018-04-27 16:45       ` Paul E. McKenney
2018-04-27 16:46         ` Steven Rostedt
2018-04-27 17:00           ` Paul E. McKenney
2018-04-27 17:05             ` Paul E. McKenney

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=20180427164416.GN26088@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=baohong.liu@intel.com \
    --cc=boqun.feng@gmail.com \
    --cc=fengguang.wu@intel.com \
    --cc=fweisbec@gmail.com \
    --cc=joelaf@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tom.zanussi@linux.intel.com \
    --cc=vedang.patel@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.