From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] tracing: Choose static tp_printk buffer by explicit nesting count
Date: Wed, 25 May 2016 15:16:40 +0200 [thread overview]
Message-ID: <20160525131640.GG3192@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <08104c3c8b9b8091fdcc6b4ca2c8c5dcc9dfd77d.1464130297.git.luto@kernel.org>
On Tue, May 24, 2016 at 03:52:28PM -0700, Andy Lutomirski wrote:
> Currently, the trace_printk code chooses which static buffer to use based
> on what type of atomic context (NMI, IRQ, etc) it's in. Simplify the
> code and make it more robust: simply count the nesting depth and choose
> a buffer based on the current nesting depth.
>
> The new code will only drop an event if we nest more than 4 deep,
> and the old code was guaranteed to malfunction if that happened.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> kernel/trace/trace.c | 83 +++++++++++++++-------------------------------------
> 1 file changed, 24 insertions(+), 59 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index a2f0b9f33e9b..4508f3bf4a97 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1986,83 +1986,41 @@ static void __trace_userstack(struct trace_array *tr, unsigned long flags)
>
> /* created for use with alloc_percpu */
> struct trace_buffer_struct {
> - char buffer[TRACE_BUF_SIZE];
> + int nesting;
> + char buffer[4][TRACE_BUF_SIZE];
> };
>
> static struct trace_buffer_struct *trace_percpu_buffer;
> /*
> + * Thise allows for lockless recording. If we're nested too deeply, then
> + * this returns NULL.
> */
> static char *get_trace_buf(void)
> {
> + struct trace_buffer_struct *buffer = this_cpu_ptr(trace_percpu_buffer);
>
> + if (!buffer || buffer->nesting >= 4)
> return NULL;
This is buggy fwiw; you need to unconditionally increment
buffer->nesting to match the unconditional decrement.
Otherwise 5 'increments' and 5 decrements will land you at -1.
>
> + return &buffer->buffer[buffer->nesting++][0];
> +}
> +
> +static void put_trace_buf(void)
> +{
> + this_cpu_dec(trace_percpu_buffer->nesting);
> }
So I don't know about tracing; but for perf this construct would not
work 'properly'.
The per context counter -- which is lost in this scheme -- guards
against in-context recursion.
Only if we nest from another context do we allow generation of a new
event.
next prev parent reply other threads:[~2016-05-25 13:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 22:52 [PATCH] tracing: Choose static tp_printk buffer by explicit nesting count Andy Lutomirski
2016-05-24 23:02 ` Steven Rostedt
2016-05-25 13:16 ` Peter Zijlstra [this message]
2016-05-25 13:36 ` Steven Rostedt
2016-05-25 17:59 ` Peter Zijlstra
2016-05-25 20:17 ` Andy Lutomirski
2016-05-25 13:20 ` Namhyung Kim
2016-05-25 20:18 ` Andy Lutomirski
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=20160525131640.GG3192@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.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 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.