public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Florent Revest <revest@chromium.org>,
	linux-trace-kernel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	bpf <bpf@vger.kernel.org>, Sven Schnelle <svens@linux.ibm.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alan Maguire <alan.maguire@oracle.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>, Guo Ren <guoren@kernel.org>
Subject: Re: [PATCH v5 06/34] function_graph: Allow multiple users to attach to function graph
Date: Wed, 20 Dec 2023 00:45:40 +0900	[thread overview]
Message-ID: <20231220004540.0af568c69ecaf9170430a383@kernel.org> (raw)
In-Reply-To: <ZYGZWWqwtSP82Sja@krava>

On Tue, 19 Dec 2023 14:23:37 +0100
Jiri Olsa <olsajiri@gmail.com> wrote:

> On Mon, Dec 18, 2023 at 10:12:45PM +0900, Masami Hiramatsu (Google) wrote:
> 
> SNIP
> 
> >  /* Both enabled by default (can be cleared by function_graph tracer flags */
> >  static bool fgraph_sleep_time = true;
> >  
> > @@ -126,9 +247,34 @@ ftrace_push_return_trace(unsigned long ret, unsigned long func,
> >  	calltime = trace_clock_local();
> >  
> >  	index = current->curr_ret_stack;
> > -	RET_STACK_INC(current->curr_ret_stack);
> > +	/* ret offset = 1 ; type = reserved */
> > +	current->ret_stack[index + FGRAPH_RET_INDEX] = 1;
> >  	ret_stack = RET_STACK(current, index);
> > +	ret_stack->ret = ret;
> > +	/*
> > +	 * The unwinders expect curr_ret_stack to point to either zero
> > +	 * or an index where to find the next ret_stack. Even though the
> > +	 * ret stack might be bogus, we want to write the ret and the
> > +	 * index to find the ret_stack before we increment the stack point.
> > +	 * If an interrupt comes in now before we increment the curr_ret_stack
> > +	 * it may blow away what we wrote. But that's fine, because the
> > +	 * index will still be correct (even though the 'ret' won't be).
> > +	 * What we worry about is the index being correct after we increment
> > +	 * the curr_ret_stack and before we update that index, as if an
> > +	 * interrupt comes in and does an unwind stack dump, it will need
> > +	 * at least a correct index!
> > +	 */
> >  	barrier();
> > +	current->curr_ret_stack += FGRAPH_RET_INDEX + 1;
> > +	/*
> > +	 * This next barrier is to ensure that an interrupt coming in
> > +	 * will not corrupt what we are about to write.
> > +	 */
> > +	barrier();
> > +
> > +	/* Still keep it reserved even if an interrupt came in */
> > +	current->ret_stack[index + FGRAPH_RET_INDEX] = 1;
> 
> seems like this was set already few lines above?

Yeah, there is a trick (trap) for interrupts between writes. We can not do
atomically write the last stack entry and increment stack index. But it must
be done for shadow unwinding insinde interrupts. Thus,

(1) write a reserve type entry on the new stack entry
(2) increment curr_ret_stack to the new stack entry
(3) rewrite the new stack entry again

If an interrupt happens between (1) and (2), stack unwinder can find the
correct latest shadow stack frame from the curr_ret_stack. This interrupts
can store their shadow stack so... wait something went wrong.

If the interrupt *overwrites* the shadow stack and (3) recovers it,
if another interrupt before (3), the shadow stack will be corrupted...

OK, I think we need a "rsrv_ret_stack" index. Basically new one will do;

(1) increment rsrv_ret_stack
(2) write a reserve type entry
(3) set curr_ret_stack = rsrv_ret_stack

And before those,

(0) if rsrv_ret_stack != curr_ret_stack, write a reserve type entry at
    rsrv_ret_stack for the previous frame (which offset can be read
    from curr_ret_stack)

Than it will never be broken.
(of course when decrement curr_ret_stack, rsrv_ret_stack is also decremented)

Thank you,

> 
> jirka
> 
> > +
> >  	ret_stack->ret = ret;
> >  	ret_stack->func = func;
> >  	ret_stack->calltime = calltime;
> > @@ -159,6 +305,12 @@ int function_graph_enter(unsigned long ret, unsigned long func,
> >  			 unsigned long frame_pointer, unsigned long *retp)
> >  {
> >  	struct ftrace_graph_ent trace;
> > +	int offset;
> > +	int start;
> > +	int type;
> > +	int val;
> > +	int cnt = 0;
> > +	int i;
> >  
> >  #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
> >  	/*
> 
> SNIP
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  reply	other threads:[~2023-12-19 15:45 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18 13:11 [PATCH v5 00/34] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph Masami Hiramatsu (Google)
2023-12-18 13:11 ` [PATCH v5 01/34] tracing: Add a comment about ftrace_regs definition Masami Hiramatsu (Google)
2024-01-05 17:12   ` Mark Rutland
2023-12-18 13:11 ` [PATCH v5 02/34] x86: tracing: Add ftrace_regs definition in the header Masami Hiramatsu (Google)
2023-12-18 13:12 ` [PATCH v5 03/34] function_graph: Convert ret_stack to a series of longs Masami Hiramatsu (Google)
2023-12-18 13:12 ` [PATCH v5 04/34] fgraph: Use BUILD_BUG_ON() to make sure we have structures divisible by long Masami Hiramatsu (Google)
2023-12-18 13:12 ` [PATCH v5 05/34] function_graph: Add an array structure that will allow multiple callbacks Masami Hiramatsu (Google)
2023-12-18 13:12 ` [PATCH v5 06/34] function_graph: Allow multiple users to attach to function graph Masami Hiramatsu (Google)
2023-12-19 13:23   ` Jiri Olsa
2023-12-19 15:45     ` Masami Hiramatsu [this message]
2023-12-26 15:24       ` Masami Hiramatsu
2023-12-18 13:12 ` [PATCH v5 07/34] function_graph: Remove logic around ftrace_graph_entry and return Masami Hiramatsu (Google)
2023-12-18 13:13 ` [PATCH v5 08/34] ftrace/function_graph: Pass fgraph_ops to function graph callbacks Masami Hiramatsu (Google)
2023-12-18 13:13 ` [PATCH v5 09/34] ftrace: Allow function_graph tracer to be enabled in instances Masami Hiramatsu (Google)
2023-12-18 13:13 ` [PATCH v5 10/34] ftrace: Allow ftrace startup flags exist without dynamic ftrace Masami Hiramatsu (Google)
2023-12-18 13:13 ` [PATCH v5 11/34] function_graph: Have the instances use their own ftrace_ops for filtering Masami Hiramatsu (Google)
2023-12-26  0:20   ` Masami Hiramatsu
2024-01-05 17:09   ` Mark Rutland
2024-01-08  1:14     ` Masami Hiramatsu
2024-01-08 12:25       ` Mark Rutland
2024-01-08 14:21         ` Mark Rutland
2024-01-08 15:03           ` Mark Rutland
2024-01-11 13:47             ` Masami Hiramatsu
2024-01-11  2:15         ` Masami Hiramatsu
2024-01-11 11:01           ` Mark Rutland
2024-01-11 13:45             ` Masami Hiramatsu
2023-12-18 13:13 ` [PATCH v5 12/34] function_graph: Use a simple LRU for fgraph_array index number Masami Hiramatsu (Google)
2023-12-18 13:14 ` [PATCH v5 13/34] function_graph: Add "task variables" per task for fgraph_ops Masami Hiramatsu (Google)
2023-12-18 13:14 ` [PATCH v5 14/34] function_graph: Move set_graph_function tests to shadow stack global var Masami Hiramatsu (Google)
2023-12-18 13:14 ` [PATCH v5 15/34] function_graph: Move graph depth stored data " Masami Hiramatsu (Google)
2023-12-18 13:14 ` [PATCH v5 16/34] function_graph: Move graph notrace bit " Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 17/34] function_graph: Implement fgraph_reserve_data() and fgraph_retrieve_data() Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 18/34] function_graph: Add selftest for passing local variables Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 19/34] function_graph: Add a new entry handler with parent_ip and ftrace_regs Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 20/34] function_graph: Add a new exit " Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 21/34] x86/ftrace: Enable HAVE_FUNCTION_GRAPH_FREGS Masami Hiramatsu (Google)
2023-12-18 13:15 ` [PATCH v5 22/34] tracing: Rename ftrace_regs_return_value to ftrace_regs_get_return_value Masami Hiramatsu (Google)
2024-01-05 17:14   ` Mark Rutland
2024-01-08  1:09     ` Masami Hiramatsu
2023-12-18 13:16 ` [PATCH v5 23/34] arm64: ftrace: Enable HAVE_FUNCTION_GRAPH_FREGS Masami Hiramatsu (Google)
2023-12-18 13:16 ` [PATCH v5 24/34] fprobe: Use ftrace_regs in fprobe entry handler Masami Hiramatsu (Google)
2023-12-19 13:23   ` Jiri Olsa
2023-12-19 13:23   ` Jiri Olsa
2023-12-19 22:51     ` Masami Hiramatsu
2023-12-18 13:16 ` [PATCH v5 25/34] fprobe: Use ftrace_regs in fprobe exit handler Masami Hiramatsu (Google)
2023-12-18 13:16 ` [PATCH v5 26/34] tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs Masami Hiramatsu (Google)
2023-12-18 13:16 ` [PATCH v5 27/34] tracing: Add ftrace_fill_perf_regs() for perf event Masami Hiramatsu (Google)
2023-12-18 13:17 ` [PATCH v5 28/34] fprobe: Rewrite fprobe on function-graph tracer Masami Hiramatsu (Google)
2023-12-19 14:39   ` Jiri Olsa
2023-12-20  1:00     ` Masami Hiramatsu
2023-12-18 13:17 ` [PATCH v5 29/34] tracing/fprobe: Remove nr_maxactive from fprobe Masami Hiramatsu (Google)
2023-12-18 13:17 ` [PATCH v5 30/34] tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS Masami Hiramatsu (Google)
2023-12-18 13:17 ` [PATCH v5 31/34] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled Masami Hiramatsu (Google)
2023-12-18 13:17 ` [PATCH v5 32/34] selftests: ftrace: Remove obsolate maxactive syntax check Masami Hiramatsu (Google)
2023-12-18 13:18 ` [PATCH v5 33/34] selftests/ftrace: Add a test case for repeating register/unregister fprobe Masami Hiramatsu (Google)
2023-12-18 13:18 ` [PATCH v5 34/34] Documentation: probes: Update fprobe on function-graph tracer Masami Hiramatsu (Google)

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=20231220004540.0af568c69ecaf9170430a383@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=acme@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=olsajiri@gmail.com \
    --cc=peterz@infradead.org \
    --cc=revest@chromium.org \
    --cc=rostedt@goodmis.org \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    /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