Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests

From: Sven Schnelle <svens@linux.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Yinan Liu <yinan@linux.alibaba.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linuxppc-dev@lists.ozlabs.org,
	Sachin Sant <sachinp@linux.ibm.com>,
	linux-kernel@vger.kernel.org, ardb@kernel.org,
	keescook@chromium.org
Subject: Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests
Date: Thu, 27 Jan 2022 13:04:41 +0100	[thread overview]
Message-ID: <yt9dy231gzae.fsf@linux.ibm.com> (raw)
In-Reply-To: <YfKGKWW5UfZ15kCW@FVFF77S0Q05N> (Mark Rutland's message of "Thu, 27 Jan 2022 11:46:49 +0000")

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.

/Sven