From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/3] tracepoints: Do not use call_rcu_sched() before early_initcall()
Date: Sun, 14 Dec 2014 17:05:49 +0000 (UTC) [thread overview]
Message-ID: <1556965801.27338.1418576749817.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20141214164803.991954802@goodmis.org>
----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: linux-kernel@vger.kernel.org
> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Mathieu Desnoyers"
> <mathieu.desnoyers@efficios.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Sent: Sunday, December 14, 2014 11:41:05 AM
> Subject: [PATCH 1/3] tracepoints: Do not use call_rcu_sched() before early_initcall()
>
> From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
>
> In order to move enabling of trace events to just after mm_init(), the
> tracepoint enable code can not use call_rcu_sched() because rcu isn't
> even initialized yet. Since this can only happen before SMP is set up
> (and even before interrupts are set up), there's no reason to use
> call_rcu_sched() at this point.
>
> Instead, create a variable called tracepoint_rcu_safe that gets enabled
> via early_initcall() and if that is not set, free the code directly
> instead of using call_rcu_sched().
>
> This allows us to enable tracepoints early without issues.
>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> kernel/tracepoint.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index 3490407dc7b7..9b90ef0ac731 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -33,6 +33,15 @@ extern struct tracepoint * const
> __stop___tracepoints_ptrs[];
> /* Set to 1 to enable tracepoint debug output */
> static const int tracepoint_debug;
>
> +/*
> + * traceoint_rcu_is_safe is set to true at early_initcall().
> + * Tracepoints can be enabled before rcu is initialized.
> + * When that happens, there's no reason to free via call_rcu()
> + * because the system isn't even in SMP mode yet, and rcu isn't
> + * initialized. Just directly free the old tracepoints instead.
> + */
> +static bool tracepoint_rcu_is_safe;
> +
> #ifdef CONFIG_MODULES
> /*
> * Tracepoint module list mutex protects the local module list.
> @@ -76,7 +85,16 @@ static inline void release_probes(struct tracepoint_func
> *old)
> if (old) {
> struct tp_probes *tp_probes = container_of(old,
> struct tp_probes, probes[0]);
> - call_rcu_sched(&tp_probes->rcu, rcu_free_old_probes);
> + /*
> + * Tracepoints can be enabled before RCU is initialized
> + * at boot up. If that is the case, do not bother using
> + * call_rcu() (because that will fail), but instead just
> + * free directly.
> + */
> + if (likely(tracepoint_rcu_is_safe))
> + call_rcu_sched(&tp_probes->rcu, rcu_free_old_probes);
> + else
> + rcu_free_old_probes(&tp_probes->rcu);
Would it makes sense to have call_rcu() and call_rcu_sched()
provide this "direct call" fallback at early boot instead
of having this in the caller ?
Thanks,
Mathieu
> }
> }
>
> @@ -518,3 +536,10 @@ void syscall_unregfunc(void)
> }
> }
> #endif
> +
> +static __init int init_tracepoint_rcu(void)
> +{
> + tracepoint_rcu_is_safe = true;
> + return 0;
> +}
> +early_initcall(init_tracepoint_rcu);
> --
> 2.1.3
>
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2014-12-14 17:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-14 16:41 [PATCH 0/3] tracing: Enable tracepoints early and allow printk to use them Steven Rostedt
2014-12-14 16:41 ` [PATCH 1/3] tracepoints: Do not use call_rcu_sched() before early_initcall() Steven Rostedt
2014-12-14 16:53 ` Steven Rostedt
2014-12-14 18:08 ` Paul E. McKenney
2014-12-14 18:15 ` Steven Rostedt
2014-12-14 18:18 ` Paul E. McKenney
2014-12-14 18:25 ` Steven Rostedt
2014-12-14 20:23 ` Paul E. McKenney
2014-12-14 17:05 ` Mathieu Desnoyers [this message]
2014-12-14 17:14 ` Steven Rostedt
2014-12-14 17:21 ` Steven Rostedt
2014-12-14 17:29 ` Mathieu Desnoyers
2014-12-14 17:44 ` Steven Rostedt
2014-12-14 18:13 ` Paul E. McKenney
2014-12-14 16:41 ` [PATCH 2/3] tracing: Move enabling tracepoints to just after mm_init() Steven Rostedt
2014-12-14 18:14 ` Paul E. McKenney
2014-12-14 18:20 ` Steven Rostedt
2014-12-14 20:26 ` Paul E. McKenney
2014-12-14 16:41 ` [PATCH 3/3] tracing: Add tp_printk cmdline to have tracepoints go to printk() Steven Rostedt
2014-12-14 17:07 ` [PATCH 0/3] tracing: Enable tracepoints early and allow printk to use them Steven Rostedt
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=1556965801.27338.1418576749817.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.