| /* SPDX-License-Identifier: GPL-2.0 */ |
| #ifndef LINUX_COMPILER_H |
| #define LINUX_COMPILER_H |
| |
| #include "../../../include/linux/compiler_types.h" |
| |
| #define WRITE_ONCE(var, val) \ |
| (*((volatile typeof(val) *)(&(var))) = (val)) |
| |
| #define READ_ONCE(var) (*((volatile typeof(var) *)(&(var)))) |
| |
| #define __aligned(x) __attribute((__aligned__(x))) |
| |
| /** |
| * data_race - mark an expression as containing intentional data races |
| * |
| * This data_race() macro is useful for situations in which data races |
| * should be forgiven. One example is diagnostic code that accesses |
| * shared variables but is not a part of the core synchronization design. |
| * For example, if accesses to a given variable are protected by a lock, |
| * except for diagnostic code, then the accesses under the lock should |
| * be plain C-language accesses and those in the diagnostic code should |
| * use data_race(). This way, KCSAN will complain if buggy lockless |
| * accesses to that variable are introduced, even if the buggy accesses |
| * are protected by READ_ONCE() or WRITE_ONCE(). |
| * |
| * This macro *does not* affect normal code generation, but is a hint |
| * to tooling that data races here are to be ignored. If the access must |
| * be atomic *and* KCSAN should ignore the access, use both data_race() |
| * and READ_ONCE(), for example, data_race(READ_ONCE(x)). |
| */ |
| #define data_race(expr) \ |
| ({ \ |
| __auto_type __v = (expr); \ |
| __v; \ |
| }) |
| |
| #endif |