[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.1911131604170.18679@pobox.suse.cz>
Date: Wed, 13 Nov 2019 16:10:36 +0100 (CET)
From: Miroslav Benes <mbenes@...e.cz>
To: Steven Rostedt <rostedt@...dmis.org>
cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
X86 ML <x86@...nel.org>, Nadav Amit <nadav.amit@...il.com>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Song Liu <songliubraving@...com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH 00/10] ftrace: Add register_ftrace_direct()
On Fri, 8 Nov 2019, Steven Rostedt wrote:
>
> Alexei mentioned that he would like a way to access the ftrace fentry
> code to jump directly to a custom eBPF trampoline instead of using
> ftrace regs caller, as he said it would be faster.
>
> I proposed a new register_ftrace_direct() function that would allow
> this to happen and still work with the ftrace infrastructure. I posted
> a proof of concept patch here:
>
> https://lore.kernel.org/r/20191023122307.756b4978@gandalf.local.home
>
> This patch series is a more complete version, and the start of the
> actual implementation. I haven't run it through my full test suite but
> it passes my smoke tests and some other custom tests I built.
>
> I also realized that I need to make the sample modules depend on X86_64
> as it has inlined assembly in it that requires that dependency.
>
> This is based on 5.4-rc6 plus the permanent patches that prevent
> a ftrace_ops from being disabled by /proc/sys/kernel/ftrace_enabled
>
> Below is the tree that contains this code.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> ftrace/direct
>
> Head SHA1: 9492654d091cb90a487ca669c58f802fa99bcd6f
>
> Enjoy,
>
> -- Steve
So I tried to run the selftests and ran into the same timeout issue we had
with live patching :/
See http://lkml.kernel.org/r/20191025115041.23186-1-mbenes@suse.cz for a possible solution.
Miroslav
Powered by blists - more mailing lists