lkml.org 
[lkml]   [2022]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests
On Thu, Jan 27, 2022 at 01:04:41PM +0100, Sven Schnelle wrote:
> Mark Rutland <mark.rutland@arm.com> writes:
>
> >> Isn't x86 relocatable in some configurations (e.g. for KASLR)?
> >>
> >> I can't see how the sort works for those cases, because the mcount_loc entries
> >> are absolute, and either:
> >>
> >> * The sorted entries will get overwritten by the unsorted relocation entries,
> >> and won't be sorted.
> >>
> >> * The sorted entries won't get overwritten, but then the absolute address will
> >> be wrong since they hadn't been relocated.
> >>
> >> How does that work?
>
> From what i've seen when looking into this ftrace sort problem x86 has a
> a relocation tool, which is run before final linking: arch/x86/tools/relocs.c
> This tools converts all the required relocations to three types:
>
> - 32 bit relocations
> - 64 bit relocations
> - inverse 32 bit relocations
>
> These are added to the end of the image.
>
> The decompressor then iterates over that array, and just adds/subtracts
> the KASLR offset - see arch/x86/boot/compressed/misc.c, handle_relocations()
>
> So IMHO x86 never uses 'real' relocations during boot, and just
> adds/subtracts. That's why the order stays the same, and the compile
> time sort works.

Ah, so those non-ELF relocations for the mcount_loc table just mean "apply the
KASLR offset here", which is equivalent for all entries.

That makes sense, thanks!

Mark.

\
 
 \ /
  Last update: 2022-01-27 13:27    [W:0.772 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site