Thread (11 messages) 11 messages, 7 authors, 2021-02-09

Re: [GIT PULL] x86/urgent for v5.11-rc7

From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-02-08 18:23:35
Also in: lkml

On Mon, Feb 08, 2021 at 09:33:00AM -0600, Josh Poimboeuf wrote:
On Mon, Feb 08, 2021 at 10:02:06AM -0500, Steven Rostedt wrote:
quoted
On Sun, 7 Feb 2021 16:45:40 -0600
Josh Poimboeuf [off-list ref] wrote:
quoted
quoted
I do suspect involved people should start thinking about how they want
to deal with functions starting with

        endbr64
        call __fentry__

instead of the call being at the very top of the function.  
FWIW, objtool's already fine with it (otherwise we would have discovered
the need to disable fcf-protection much sooner).
And this doesn't really affect tracing (note, another user that might be
affected is live kernel patching).
Good point, livepatch is indeed affected.  Is there a better way to get
the "call __fentry__" address for a given function?


/*
 * Convert a function address into the appropriate ftrace location.
 *
 * Usually this is just the address of the function, but on some architectures
 * it's more complicated so allow them to provide a custom behaviour.
 */
#ifndef klp_get_ftrace_location
static unsigned long klp_get_ftrace_location(unsigned long faddr)
{
	return faddr;
}
#endif
I suppose the trivial fix is to see if it points to endbr64 and if so,
increment the addr by the length of that.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help