linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options
@ 2019-12-12  0:07 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 ` [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options Paul E. McKenney
  0 siblings, 2 replies; 3+ messages in thread
From: Marco Elver @ 2019-12-12  0:07 UTC (permalink / raw)
  To: elver
  Cc: torvalds, paulmck, mingo, peterz, will, tglx, akpm, stern,
	dvyukov, mark.rutland, parri.andrea, edumazet, linux-doc,
	kasan-dev, linux-kernel

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>
---
 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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [PATCH -rcu/kcsan 2/2] kcsan: Add __no_kcsan function attribute
  2019-12-12  0:07 [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options Marco Elver
@ 2019-12-12  0:07 ` Marco Elver
  2019-12-12  1:20 ` [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options Paul E. McKenney
  1 sibling, 0 replies; 3+ messages in thread
From: Marco Elver @ 2019-12-12  0:07 UTC (permalink / raw)
  To: elver
  Cc: torvalds, paulmck, mingo, peterz, will, tglx, akpm, stern,
	dvyukov, mark.rutland, parri.andrea, edumazet, linux-doc,
	kasan-dev, linux-kernel

Since the use of -fsanitize=thread is an implementation detail of KCSAN,
the name __no_sanitize_thread could be misleading if used widely.
Instead, we introduce the __no_kcsan attribute which is shorter and more
accurate in the context of KCSAN.

This matches the attribute name __no_kcsan_or_inline. The use of
__kcsan_or_inline itself is still required for __always_inline functions
to retain compatibility with older compilers.

Signed-off-by: Marco Elver <elver@google.com>
---
 include/linux/compiler-gcc.h | 3 +--
 include/linux/compiler.h     | 7 +++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 0eb2a1cc411d..cf294faec2f8 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -146,8 +146,7 @@
 #endif
 
 #if defined(__SANITIZE_THREAD__) && __has_attribute(__no_sanitize_thread__)
-#define __no_sanitize_thread                                                   \
-	__attribute__((__noinline__)) __attribute__((no_sanitize_thread))
+#define __no_sanitize_thread __attribute__((no_sanitize_thread))
 #else
 #define __no_sanitize_thread
 #endif
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7d3e77781578..a35d5493eeaa 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -207,12 +207,15 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 # define __no_kasan_or_inline __always_inline
 #endif
 
+#define __no_kcsan __no_sanitize_thread
 #ifdef __SANITIZE_THREAD__
 /*
  * Rely on __SANITIZE_THREAD__ instead of CONFIG_KCSAN, to avoid not inlining in
- * compilation units where instrumentation is disabled.
+ * compilation units where instrumentation is disabled. The attribute 'noinline'
+ * is required for older compilers, where implicit inlining of very small
+ * functions renders __no_sanitize_thread ineffective.
  */
-# define __no_kcsan_or_inline __no_sanitize_thread notrace __maybe_unused
+# define __no_kcsan_or_inline __no_kcsan noinline notrace __maybe_unused
 # define __no_sanitize_or_inline __no_kcsan_or_inline
 #else
 # define __no_kcsan_or_inline __always_inline
-- 
2.24.0.525.g8f36a354ae-goog


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Paul E. McKenney @ 2019-12-12  1:20 UTC (permalink / raw)
  To: Marco Elver
  Cc: torvalds, mingo, peterz, will, tglx, akpm, stern, dvyukov,
	mark.rutland, parri.andrea, edumazet, linux-doc, kasan-dev,
	linux-kernel

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
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-12-12  1:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [PATCH -rcu/kcsan 1/2] kcsan: Document static blacklisting options Paul E. McKenney

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).