linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: 王贇 <yun.wang@linux.alibaba.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	live-patching@vger.kernel.org, linux-riscv@lists.infradead.org,
	"Miroslav Benes" <mbenes@suse.cz>,
	"Joe Lawrence" <joe.lawrence@redhat.com>,
	"Helge Deller" <deller@gmx.de>,
	x86@kernel.org, linux-csky@vger.kernel.org,
	"Ingo Molnar" <mingo@redhat.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	linux-parisc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Guo Ren" <guoren@kernel.org>,
	"Colin Ian King" <colin.king@canonical.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] tracing: Have all levels of checks prevent recursion
Date: Mon, 18 Oct 2021 12:19:20 +0200	[thread overview]
Message-ID: <YW1KKCFallDG+E01@alley> (raw)
In-Reply-To: <20211015110035.14813389@gandalf.local.home>

On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> 
> While writing an email explaining the "bit = 0" logic for a discussion on
> making ftrace_test_recursion_trylock() disable preemption, I discovered a
> path that makes the "not do the logic if bit is zero" unsafe.
> 
> Since we want to encourage architectures to implement all ftrace features,
> having them slow down due to this extra logic may encourage the
> maintainers to update to the latest ftrace features. And because this
> logic is only safe for them, remove it completely.
> 
>  [*] There is on layer of recursion that is allowed, and that is to allow
>      for the transition between interrupt context (normal -> softirq ->
>      irq -> NMI), because a trace may occur before the context update is
>      visible to the trace recursion logic.
> 
> diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h
> index a9f9c5714e65..168fdf07419a 100644
> --- a/include/linux/trace_recursion.h
> +++ b/include/linux/trace_recursion.h
> @@ -165,40 +147,29 @@ static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsign
>  	unsigned int val = READ_ONCE(current->trace_recursion);
>  	int bit;
>  
> -	/* A previous recursion check was made */
> -	if ((val & TRACE_CONTEXT_MASK) > max)
> -		return 0;

@max parameter is no longer used.

> -
>  	bit = trace_get_context_bit() + start;
>  	if (unlikely(val & (1 << bit))) {
>  		/*
>  		 * It could be that preempt_count has not been updated during
>  		 * a switch between contexts. Allow for a single recursion.
>  		 */
> -		bit = TRACE_TRANSITION_BIT;
> +		bit = TRACE_CTX_TRANSITION + start;

I just want to be sure that I understand it correctly.

The transition bit is the same for all contexts. It will allow one
recursion only in one context.

IMHO, the same problem (not-yet-updated preempt_count) might happen
in any transition between contexts: normal -> soft IRQ -> IRQ -> NMI.

Well, I am not sure what exacly it means "preempt_count has not been
updated during a switch between contexts."

   Is it that a function in the interrupt entry code is traced before
   preempt_count is updated?

   Or that an interrupt entry is interrupted by a higher level
   interrupt, e.g. IRQ entry code interrupted by NMI?


I guess that it is the first case. It would mean that the above
function allows one mistake (one traced funtion in an interrupt entry
code before the entry code updates preempt_count).

Do I get it correctly?
Is this what we want?


Could we please update the comment? I mean to say if it is a race
or if we trace a function that should not get traced.

>  		if (val & (1 << bit)) {
>  			do_ftrace_record_recursion(ip, pip);
>  			return -1;
>  		}
> -	} else {
> -		/* Normal check passed, clear the transition to allow it again */
> -		val &= ~(1 << TRACE_TRANSITION_BIT);
>  	}
>  
>  	val |= 1 << bit;
>  	current->trace_recursion = val;
>  	barrier();
>  
> -	return bit + 1;
> +	return bit;
>  }
>  
>  static __always_inline void trace_clear_recursion(int bit)
>  {
> -	if (!bit)
> -		return;
> -
>  	barrier();
> -	bit--;
>  	trace_recursion_clear(bit);
>  }

Otherwise, the change looks great. It simplifies that logic a lot.
I think that I start understanding it ;-)

Best Regards,
Petr

  parent reply	other threads:[~2021-10-18 10:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 15:00 [PATCH] tracing: Have all levels of checks prevent recursion Steven Rostedt
2021-10-15 16:17 ` Peter Zijlstra
2021-10-15 17:35   ` Steven Rostedt
2021-10-15 17:58     ` Steven Rostedt
2021-10-15 18:04       ` Peter Zijlstra
2021-10-15 18:20         ` Steven Rostedt
2021-10-15 18:24           ` Peter Zijlstra
2021-10-15 19:00             ` Steven Rostedt
2021-10-15 18:25           ` Steven Rostedt
2023-07-21 15:34             ` Alexander Lobakin
2023-07-21 16:00               ` Steven Rostedt
2023-07-21 16:06                 ` Alexander Lobakin
2023-07-21 16:26                   ` Steven Rostedt
2023-07-22  1:22                     ` Jakub Kicinski
2021-10-18 10:19 ` Petr Mladek [this message]
2021-10-18 13:50   ` Steven Rostedt
2021-10-18 15:09     ` Petr Mladek
2021-10-19  2:02   ` Steven Rostedt
2021-10-19  6:41     ` Petr Mladek
2021-10-19 13:00       ` 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=YW1KKCFallDG+E01@alley \
    --to=pmladek@suse.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bp@alien8.de \
    --cc=colin.king@canonical.com \
    --cc=deller@gmx.de \
    --cc=guoren@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=jszhang@kernel.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yun.wang@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).