Re: [PATCH] lkdtm: turn off kcov for lkdtm_rodata_do_nothing:

[Arnd Bergmann]

On Tue, Mar 28, 2017 at 12:22 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> Hi,
>
> On Tue, Mar 28, 2017 at 12:00:15PM +0200, Dmitry Vyukov wrote:
>> On Tue, Mar 28, 2017 at 11:57 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> > I ran into a link error on ARM64 for lkdtm_rodata_do_nothing:
>> >
>> > drivers/misc/built-in.o: In function `lkdtm_rodata_do_nothing':
>> > :(.rodata+0x68c8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `__sanitizer_cov_trace_pc' defined in .text section in kernel/built-in.o
>> >
>> > I did not analyze this further, but my theory is that we would need a trampoline
>> > to call __sanitizer_cov_trace_pc(), but the linker (correctly) only adds trampolines
>> > for callers in executable sections.
>
> For reference, is this a "large" config, e.g. allyesconfig?

It's a randconfig build, and I'm guessing that it's large, but I have
not checked
the size of the sections. This was the first time I ran into it after months of
building randconfig kernels without anything having triggered it recently.

> I'm aware that at least as recently as GCC 6 there were issues with
> veneer generation for calls across sections (which I personally saw with
> calls from .init.text to .text) when the kernel was sufficiently large.

We have had problems with veneers no arm32 in the past, and ld definitely
doesn't create them for calls from inside of non-executable sections, so
the typical fix was to put all code that needs veneers into executable sections.

Clearly that cannot work for this particular case.

> FWIW, I have no problem building a v4.11-rc3 kernel with both KCOV and
> LKDTM using the Linaro 15.08 aarch64-linux-gnu GCC 5 toolchain. Which
> toolchain are you using?

This is a gcc-7.0.1 snapshot from last week, and a somewhat older
binutils: GNU ld (GNU Binutils) 2.27.51.20161215

> No strong feelings on this patch, but it may be indicative of a larger
> problem, and we probably don't want to play whack-a-mole to fix
> relocation truncation more generally.

I have not seen this problem in allyesconfig or any other randconfig build,
so it's certainly likely that some other setting must be there to trigger this.

I've recreated the problem using an allyesconfig build with this change
to turn off -mcmodel=large:

@@ -283,7 +283,6 @@
 CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
 CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
 CONFIG_HAVE_ARCH_HUGE_VMAP=y
-CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
 CONFIG_MODULES_USE_ELF_RELA=y
 CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
 CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
@@ -529,7 +528,7 @@
 CONFIG_ARM64_ERRATUM_832075=y
 CONFIG_ARM64_ERRATUM_834220=y
 CONFIG_ARM64_ERRATUM_845719=y
-CONFIG_ARM64_ERRATUM_843419=y
+# CONFIG_ARM64_ERRATUM_843419 is not set
 CONFIG_CAVIUM_ERRATUM_22375=y
 CONFIG_CAVIUM_ERRATUM_23144=y
 CONFIG_CAVIUM_ERRATUM_23154=y
@@ -643,10 +642,7 @@
 # ARMv8.2 architectural features
 #
 CONFIG_ARM64_UAO=y
-CONFIG_ARM64_MODULE_CMODEL_LARGE=y
-CONFIG_ARM64_MODULE_PLTS=y
-CONFIG_RELOCATABLE=y
-CONFIG_RANDOMIZE_BASE=y
+# CONFIG_RANDOMIZE_BASE is not set

 #
 # Boot options

     Arnd