Cregit: Linux 6.19: compiler.h

Contributors: 6
Author	Tokens	Token Proportion	Commits	Commit Proportion
Michael S. Tsirkin	44	75.86%	3	37.50%
Yufeng Wang	8	13.79%	1	12.50%
Shunsuke Mie	3	5.17%	1	12.50%
Mark Rutland	1	1.72%	1	12.50%
H. Peter Anvin	1	1.72%	1	12.50%
Greg Kroah-Hartman	1	1.72%	1	12.50%
Total	58		8

/* 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