Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1368420
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 |
| Date | 2016-03-31 18:10 +0200 |
| Message-ID | <riNku-7EN-9@gated-at.bofh.it> (permalink) |
| References | <riLiG-5Uq-9@gated-at.bofh.it> <riLLI-6lZ-13@gated-at.bofh.it> <riMoq-6WJ-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: > On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland <mark.rutland@arm.com> wrote: > > Hi, > > > > On Thu, Mar 31, 2016 at 03:54:45PM +0200, Alexander Potapenko wrote: > >> Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of > >> arch/arm64/lib/delay.c > > > > Why do we disable instrumentation of delay.c? > The main purpose of kcov is collecting coverage from syscalls. As far > as I understand, coverage of functions from delay.c doesn't > deterministically depend on the syscalls being called and their > arguments. > The initial kcov implementation > (https://github.com/torvalds/linux/commit/5c9a8750a6409c63a0f01d51a9024861022f6593) > disabled instrumentation of arch/x86/lib/delay.c, so I just copied > that chunk. > > > What exactly does kcov instrumentation imply? Does it require certain > > data to be mapped or certain functions to be callable while instrumented > > functions are called? > Yes, there is __sanitizer_cov_trace_pc() that must be callable. That will definitely be a problem for the KVM code which is run at a different exception level with a different memory map. For GCOV, KASAN, and UBSAN we simply disable instrumentation of that code [1]. We should be able to do similarly for KCOV. > At boot time |current->kcov_mode| zero, so it virtually does nothing. > > Currently kcov instrumentation is disabled for the following files: > 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. > 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. > 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. > My patch explicitly disables instrumentation for arch/arm64/lib/delay.c. > I never had problems with arch/arm64/boot/* and arch/arm64/kernel/* in > the 3.18 kernel, although instrumentation of the corresponding x86 > code is claimed to cause boot-time hangs. > We can act conservatively and still disable instrumentation for these > two dirs just to make sure nothing breaks in the future. I'd rather that we understood why instrumentation of the above is disabled, such that we can make a sensible decision from the outset. > > We have some C code that is run outside of the normal kernel context > > (e.g. EFI stub, KVM hyp code), and I suspect it may be necessary to > > disable instrumentation for those also. > EFI stub and a number of other files is already disabled by the > initial kcov patch. > I understand there might be some code specific to ARM64 that I may > have overlooked, so I'd be grateful if someone could try the patch out > with the upstream kernel. The only such code that I'm immediately aware of is the hyp-context KVM code, as mentioned above. Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/416790.html
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 16:00 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 16:10 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Mark Rutland <mark.rutland@arm.com> - 2016-03-31 16:30 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 17:10 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Mark Rutland <mark.rutland@arm.com> - 2016-03-31 18:10 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 18:40 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 18:50 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Mark Rutland <mark.rutland@arm.com> - 2016-03-31 19:20 +0200
Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko <glider@google.com> - 2016-03-31 19:20 +0200
csiph-web