Something went wrong. Try again.
(I'm so sorry!) Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
Something went wrong. Try again.
123456789101112131415161718192021222324252627282930313233343536373839404142434445/* SPDX-License-Identifier: GPL-2.0 */#ifndef LINUX_COMPILER_H#define LINUX_COMPILER_H
/* Avoid redefinition warnings */#undef __user#include "../../../include/linux/compiler_types.h"#undef __user#define __user
#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; \})
#define __must_check
#endif