Re: [PATCH] arm64/ftrace: Make function graph use ftrace directly

From: Mark Rutland <mark.rutland@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Chengming Zhou <zhouchengming@bytedance.com>,
	mingo@redhat.com, catalin.marinas@arm.com, will@kernel.org,
	broonie@kernel.org, songmuchun@bytedance.com,
	qirui.001@bytedance.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/ftrace: Make function graph use ftrace directly
Date: Tue, 22 Feb 2022 16:07:04 +0000	[thread overview]
Message-ID: <YhUKKOF/ZP167ueN@lakrids> (raw)
In-Reply-To: <20220222105218.28e3d5aa@gandalf.local.home>

On Tue, Feb 22, 2022 at 10:52:18AM -0500, Steven Rostedt wrote:
> On Tue, 22 Feb 2022 21:00:49 +0800
> Chengming Zhou <zhouchengming@bytedance.com> wrote:
> 
> > As we do in commit 0c0593b45c9b ("x86/ftrace: Make function graph
> > use ftrace directly"), we don't need special hook for graph tracer,
> > but instead we use graph_ops:func function to install return_hooker.
> > 
> > Since commit 3b23e4991fb6 ("arm64: implement ftrace with regs") add
> > implementation for FTRACE_WITH_REGS on arm64, we can easily adopt
> > the same optimization on arm64.
> 
> Note. Ideally we want it to hook with DYNAMIC_FTARCE_WITH_ARGS, and not
> FTRACE_WITH_REGS. If arm64 is like x86_64, saving all regs at every
> function call has a bit more overhead than saving the minimum. The
> DYNAMIC_FTRACE_WITH_ARGS, means that the minimum is still saved, but now
> exposes the arguments and the stack pointer, which function_graph_tracer
> needs.

FWIW, I'd been meaning to take a look at that.

On arm64 we can't really create a full pt_regs without taking an
exception because there's a bunch of stuff in pt_regs that we can only
snapshot at an exception boundary (e.g. PSTATE, which is what Arm calls
the internal processor flags). I'd wanted to look at whether we could
implement FTRACE_WITH_ARGS without FTRACE_WITH_REGS.

For kprobes & kreprobes we snapshot the real flags at function entry
time and give made up values at function return time, which is less
than ideal because there'll be spurious differences in the flags across
the two.

It might be worth a chat at plumbers about how we could align this a bit
better (e.g. with k(ret)probes having an args-only mode too).

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel