39 lines
1.4 KiB
C
39 lines
1.4 KiB
C
/* 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 __v = (expr); \
|
|
__v; \
|
|
})
|
|
|
|
#endif
|