Very similar to commit:
b94d45b6bbb4 ("seqlock: Allow KASAN to fail optimizing")
mark UBSAN as failing to optimize and not suitable for release builds.
Reported-by: kernel test robot <[email protected]>
Closes:
https://lore.kernel.org/oe-kbuild-all/[email protected]/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123873
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
Debian folks, can you please remove CONFIG_UBSAN=y from your builds,
this is, per GCC devs, not a feature suitable for production!
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index c00063dffba3..436f05bf5dd7 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -1259,14 +1259,14 @@ static __always_inline void
__scoped_seqlock_cleanup(struct ss_tmp *sst)
extern void __scoped_seqlock_invalid_target(void);
-#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) ||
defined(CONFIG_KASAN)
+#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) ||
defined(CONFIG_KASAN) || defined(CONFIG_UBSAN)
/*
* For some reason some GCC-8 architectures (nios2, alpha) have trouble
* determining that the ss_done state is impossible in __scoped_seqlock_next()
* below.
*
- * Similarly KASAN is known to confuse compilers enough to break this. But we
- * don't care about code quality for KASAN builds anyway.
+ * Similarly *SAN is known to confuse compilers enough to break this. But we
+ * don't care about code quality for *SAN builds anyway.
*/
static inline void __scoped_seqlock_bug(void) { }
#else
