On Wed, 13 Nov 2019, Alan Stern wrote:
> On Wed, 13 Nov 2019, Marco Elver wrote:
>
> > An expression works fine. The below patch would work with KCSAN, and all
> > your above examples work.
> >
> > Re name: would it make sense to more directly convey the intent? I.e.
> > "this expression can race, and it's fine that the result is approximate
> > if it does"?
> >
> > My vote would go to something like 'smp_lossy' or 'lossy_race' -- but
> > don't have a strong preference, and would also be fine with 'data_race'.
> > Whatever is most legible. Comments?
>
> Lossiness isn't really relevant. Things like sticky writes work
> perfectly well with data races; they don't lose anything.
>
> My preference would be for "data_race" or something very similar
> ("racy"? "race_ok"?). That's the whole point -- we know the
> operation can be part of a data race and we don't care.
Makes sense. Let's stick with 'data_race' then.
As Linus pointed out this won't yet work for void types and
if-statements. How frequent would that use be? Should it even be
encouraged?
I'll add this as a patch for the next version of the KCSAN patch series.
Thanks,
-- Marco
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 0b6506b9dd11..a97f323b61e3 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,6 +308,26 @@ unsigned long read_word_at_a_time(const void *addr)
__u.__val; \
})
+#include <linux/kcsan.h>
+
+/*
+ * data_race: macro to document that accesses in an expression may conflict with
+ * other concurrent accesses resulting in data races, but the resulting
+ * behaviour is deemed safe regardless.
+ *
+ * This macro *does not* affect normal code generation, but is a hint to tooling
+ * that data races here are intentional.
+ */
+#define data_race(expr) \
+ ({ \
+ typeof(({ expr; })) __val; \
+ kcsan_nestable_atomic_begin(); \
+ __val = ({ expr; }); \
+ kcsan_nestable_atomic_end(); \
+ __val; \
+ })
+#else
+
#endif /* __KERNEL__ */
/*
