On Thu, Mar 31, 2016 at 06:33:24PM +0200, Alexander Potapenko wrote:

On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland [off-list ref] wrote:

quoted

On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote:

quoted

Currently kcov instrumentation is disabled for the following files:

quoted

arch/x86/boot/*
arch/x86/boot/compressed/*
arch/x86/entry/vdso/*
arch/x86/realmode/rm/*

These are executed outside of the usual kernel context / address space,
so excluding these makes sense to me.

quoted

arch/x86/kernel/*
arch/x86/kernel/apic/*
arch/x86/kernel/cpu/common.c
arch/x86/kernel/cpu/perf_event.c
arch/x86/lib/delay.c
arch/x86/mm/tlb.c

For these, it's not immediately clear to me why instrumentation is
disabled, so I don't know whether or not we can instrument the analogous
arm64 code.

According to the comments in
https://github.com/torvalds/linux/commit/5c9a8750a6409c63a0f01d51a9024861022f6593,
instrumentation of arch/x86/kernel/apic/* and arch/x86/lib/delay.c
leads to non-deterministic coverage,

To what extent does determinism matter? Are we just ruling out the worst
cases, or is this likely to turn into a whack-a-mole game?

Do we exclude clocksources and other driver code?

Looking at the arm64 delay timer code, it looks like everything will be
inlined (and therefore coverage should be deterministic so long as the
delay functions are called deterministically). That said, the same looks
basically true of the x86 code, so I guess I've misunderstood.

instrumenting others prevent the kernel from booting.

I haven't been able to come up with a scenario whereby kcov would be
fatal for the above, so it's difficult to say if we have equivalent
problems.

For reference, do we have any examples as to why any of these prevent
booting?

quoted

quoted

Only a handful of the above have corresponding files in arch/arm64:
arch/arm64/boot/*
arch/arm64/kernel/*
arch/arm64/lib/delay.c

We have arch/arm64/kernel/perf_event.c, and a couple of other files that
are directly analogous, even if the paths don't quite line up.

Ok, it makes sense to also disable arch/arm64/kernel/perf_event.c then.

Potentially, though it really depends on why it was excluded on x86.

Some of the arm64 perf code lives in drivers/perf/arm_pmu.c, also.

Thanks,
Mark.