From: Michal Marek <mmarek@suse.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>,
James Morse <james.morse@arm.com>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] kcov: reject open when kernel not instrumented
Date: Wed, 15 Jun 2016 18:21:03 +0200 [thread overview]
Message-ID: <5761806F.5020103@suse.com> (raw)
In-Reply-To: <1466005756-15626-1-git-send-email-mark.rutland@arm.com>
Dne 15.6.2016 v 17:49 Mark Rutland napsal(a):
> If the toolchain does not support -fsanitize-coverage=trace-pc, we blat
> this option from CFLAGS_KCOV, and build the kernel without
> instrumentation, even if CONFIG_KCOV was selected. However, we still
> build the rest of the kcov infrastructure, and expose a kcov file under
> debugfs. This can be confusing, as the kernel will appear to support
> kcov, yet will never manage to sample any trace PC values. While we do
> note this fact at build time, this may be missed, and a user may not
> have access to build logs.
>
> This patch adds an artificial CONFIG symbol, CONFIG_KCOV_CC, that is
> only set when the toolchain supports -fsanitize-coverage=trace-pc, and
> hence the kernel is built with instrumentation. When this is not the
> case, the kernel will return -ENOTSUPP if userspace attempts to open the
> kcov debugfs file, indicating that kcov functionality is unavailable.
Hi Mark,
please use a define outside the CONFIG_ namespace, because it is not a
config option that one can find in .config or a Kconfig file. We already
have CC_HAVE_ASM_GOTO, CC_USING_FENTRY and similar in the kernel.
Thanks,
Michal
next prev parent reply other threads:[~2016-06-15 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 15:49 [PATCH] kcov: reject open when kernel not instrumented Mark Rutland
2016-06-15 15:52 ` Dmitry Vyukov
2016-06-15 16:21 ` Michal Marek [this message]
2016-06-15 16:34 ` Mark Rutland
2016-06-15 16:36 ` Dmitry Vyukov
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=5761806F.5020103@suse.com \
--to=mmarek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.