OSDN Git Service

[TSAN] Add optional support for distinguishing volatiles
authorDmitry Vyukov <dvyukov@google.com>
Wed, 22 Apr 2020 14:01:33 +0000 (16:01 +0200)
committerDmitry Vyukov <dvyukov@google.com>
Wed, 22 Apr 2020 15:27:09 +0000 (17:27 +0200)
commit5a2c31116f412c3b6888be361137efd705e05814
treee7017912e055419e7f29d079996220d79c2a6842
parentec16df706682c064a3e38e01068d5b2512971aa4
[TSAN] Add optional support for distinguishing volatiles

Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing volatiles.

One such environment are OS kernels, where volatile is still used in
various places for various reasons, and often declare volatile to be
"safe enough" even in multi-threaded contexts. One such example is the
Linux kernel, which implements various synchronization primitives using
volatile (READ_ONCE(), WRITE_ONCE()). Here the Kernel Concurrency
Sanitizer (KCSAN) [1], is a runtime that uses TSAN instrumentation but
otherwise implements a very different approach to race detection from
TSAN.

While in the Linux kernel it is generally discouraged to use volatiles
explicitly, the topic will likely come up again, and we will eventually
need to distinguish volatile accesses [2]. The other use-case is
ignoring data races on specially marked variables in the kernel, for
example bit-flags (here we may hide 'volatile' behind a different name
such as 'no_data_race').

[1] https://github.com/google/ktsan/wiki/KCSAN
[2] https://lkml.kernel.org/r/CANpmjNOfXNE-Zh3MNP=-gmnhvKbsfUfTtWkyg_=VqTxS4nnptQ@mail.gmail.com

Author: melver (Marco Elver)
Reviewed-in: https://reviews.llvm.org/D78554
llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
llvm/test/Instrumentation/ThreadSanitizer/volatile.ll [new file with mode: 0644]