This is an archive of the discontinued LLVM Phabricator instance.

[TSAN] Add optional support for distinguishing volatiles
ClosedPublic

Authored by melver on Apr 21 2020, 5:08 AM.

Details

Reviewers
dvyukov
glider
Group Reviewers
Restricted Project
Summary

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

Diff Detail

Event Timeline

melver created this revision.Apr 21 2020, 5:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 21 2020, 5:08 AM

I am not opposed to adding this in general. Andrey did the same for KTSAN in gcc long time ago.
However, this feature will be present only in the newest clang and not in gcc. So what is the use story for kernel? Do we make KCSAN require the newest clang? I think majority of kernel developers use gcc.

I am not opposed to adding this in general. Andrey did the same for KTSAN in gcc long time ago.
However, this feature will be present only in the newest clang and not in gcc. So what is the use story for kernel? Do we make KCSAN require the newest clang? I think majority of kernel developers use gcc.

I am planning to make the same change to gcc. And yes, it's a problem that it's only the newest versions that will support this. But, for now it's not urgent and no kernel dev is explicitly requesting this. But my feeling is that eventually we will need it, and we will be glad to have this option when that day comes.

FYI the build failures seem entirely unrelated and look like LLDB is broken.

I am not opposed to adding this in general. Andrey did the same for KTSAN in gcc long time ago.
However, this feature will be present only in the newest clang and not in gcc. So what is the use story for kernel? Do we make KCSAN require the newest clang? I think majority of kernel developers use gcc.

I am planning to make the same change to gcc. And yes, it's a problem that it's only the newest versions that will support this. But, for now it's not urgent and no kernel dev is explicitly requesting this. But my feeling is that eventually we will need it, and we will be glad to have this option when that day comes.

Ack. At the very least we will be able to use this on syzbot.

dvyukov accepted this revision.Apr 21 2020, 8:41 AM
This revision is now accepted and ready to land.Apr 21 2020, 8:41 AM
dvyukov added a reviewer: Restricted Project.Apr 21 2020, 8:41 AM

Any objections, anybody?

Marco, do you want me to land this?

Any objections, anybody?

Marco, do you want me to land this?

Thanks! I don't think I have access to land.

Any objections, anybody?

Marco, do you want me to land this?

Thanks! I don't think I have access to land.

I see no further complaints. Please go ahead and land. (I also have a prototype patch for KCSAN which works. Now on to GCC...)

dvyukov closed this revision.Apr 22 2020, 8:30 AM

ninja check-tsan passed.
ninja check-all kills my self-isolation machine, so let's assume it works...
committed as: https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814