Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 11 Dec 2019 17:20:00 -0800
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
Message-ID: <20191212012000.GP2889@paulmck-ThinkPad-P72>
Reply-To: paulmck@kernel.org
References: <20191212000709.166889-1-elver@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191212000709.166889-1-elver@google.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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
>