From: Mark Rutland <mark.rutland@arm.com>
To: Alexander Potapenko <glider@google.com>
Cc: Dmitriy Vyukov <dvyukov@google.com>,
catalin.marinas@arm.com, quentin.casasnovas@oracle.com,
will.deacon@arm.com, Kostya Serebryany <kcc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
syzkaller@googlegroups.com, LKML <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
marc.zyngier@arm.com, christoffer.dall@linaro.org
Subject: Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64
Date: Thu, 31 Mar 2016 17:00:53 +0100 [thread overview]
Message-ID: <20160331160052.GA26393@leverpostej> (raw)
In-Reply-To: <CAG_fn=V+e=+-svWOCUirOy4SvBNgJR5JWCFDU3uE3aKwz9ihvw@mail.gmail.com>
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
next prev parent reply other threads:[~2016-03-31 16:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 13:54 [PATCH v1] arm64: allow building with kcov coverage on ARM64 Alexander Potapenko
2016-03-31 14:02 ` Alexander Potapenko
2016-03-31 14:29 ` Mark Rutland
2016-03-31 15:09 ` Alexander Potapenko
2016-03-31 16:00 ` Mark Rutland [this message]
2016-03-31 16:33 ` Alexander Potapenko
2016-03-31 16:43 ` Alexander Potapenko
2016-03-31 17:14 ` Mark Rutland
2016-03-31 17:18 ` Alexander Potapenko
2016-04-04 17:30 ` Dmitry Vyukov
2016-04-12 11:17 ` Alexander Potapenko
2016-04-13 16:12 ` James Morse
2016-04-13 16:35 ` Alexander Potapenko
2016-04-13 17:01 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160331160052.GA26393@leverpostej \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kcc@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=quentin.casasnovas@oracle.com \
--cc=syzkaller@googlegroups.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).