linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Marco Elver <elver@google.com>
Cc: torvalds@linux-foundation.org, mingo@kernel.org,
	peterz@infradead.org, will@kernel.org, tglx@linutronix.de,
	akpm@linux-foundation.org, stern@rowland.harvard.edu,
	dvyukov@google.com, mark.rutland@arm.com, parri.andrea@gmail.com,
	edumazet@google.com, linux-doc@vger.kernel.org,
	kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options
Date: Wed, 11 Dec 2019 17:20:00 -0800	[thread overview]
Message-ID: <20191212012000.GP2889@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20191212000709.166889-1-elver@google.com>

On Thu, Dec 12, 2019 at 01:07:08AM +0100, Marco Elver wrote:
> Updates the section on "Selective analysis", listing all available
> options to blacklist reporting data races for: specific accesses,
> functions, compilation units, and entire directories.
> 
> These options should provide adequate control for maintainers to opt out
> of KCSAN analysis at varying levels of granularity. It is hoped to
> provide the required control to reflect preferences for handling data
> races across the kernel.
> 
> Signed-off-by: Marco Elver <elver@google.com>

Both queued for testing and review, thank you!

							Thanx, Paul

> ---
>  Documentation/dev-tools/kcsan.rst | 24 +++++++++++++++++-------
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst
> index a6f4f92df2fa..65a0be513b7d 100644
> --- a/Documentation/dev-tools/kcsan.rst
> +++ b/Documentation/dev-tools/kcsan.rst
> @@ -101,18 +101,28 @@ instrumentation or e.g. DMA accesses.
>  Selective analysis
>  ~~~~~~~~~~~~~~~~~~
>  
> -To disable KCSAN data race detection for an entire subsystem, add to the
> -respective ``Makefile``::
> +It may be desirable to disable data race detection for specific accesses,
> +functions, compilation units, or entire subsystems.  For static blacklisting,
> +the below options are available:
>  
> -    KCSAN_SANITIZE := n
> +* KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that
> +  any data races due to accesses in ``expr`` should be ignored and resulting
> +  behaviour when encountering a data race is deemed safe.
> +
> +* Disabling data race detection for entire functions can be accomplished by
> +  using the function attribute ``__no_kcsan`` (or ``__no_kcsan_or_inline`` for
> +  ``__always_inline`` functions). To dynamically control for which functions
> +  data races are reported, see the `debugfs`_ blacklist/whitelist feature.
>  
> -To disable KCSAN on a per-file basis, add to the ``Makefile``::
> +* To disable data race detection for a particular compilation unit, add to the
> +  ``Makefile``::
>  
>      KCSAN_SANITIZE_file.o := n
>  
> -KCSAN also understands the ``data_race(expr)`` annotation, which tells KCSAN
> -that any data races due to accesses in ``expr`` should be ignored and resulting
> -behaviour when encountering a data race is deemed safe.
> +* To disable data race detection for all compilation units listed in a
> +  ``Makefile``, add to the respective ``Makefile``::
> +
> +    KCSAN_SANITIZE := n
>  
>  debugfs
>  ~~~~~~~
> -- 
> 2.24.0.525.g8f36a354ae-goog
> 

      parent reply	other threads:[~2019-12-12  1:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  0:07 [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options Marco Elver
2019-12-12  0:07 ` [PATCH -rcu/kcsan 2/2] kcsan: Add __no_kcsan function attribute Marco Elver
2019-12-12  1:20 ` Paul E. McKenney [this message]

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=20191212012000.GP2889@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /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).