On Thu, Oct 19, 2023 at 05:44:30PM +0300, Andy Shevchenko wrote:
> So, what I have done so far.
> 1) I have cleaned ccaches and stuff as I used it to avoid collisions;
> 2) I have confirmed that CONFIG_DEBUG_LIST affects boot, the repo
> I'm using is published here [0][1];
> 3) reverted quota patches until before this merge ([2] - last patch),
> still boots;
> 4) reverted disabling of CONFIG_DEBUG_LIST [2], doesn't boot;
> 5) okay, rebased on top of merge, i.e. 1500e7e0726e, with DEBUG_LIST [3],
> doesn't boot;
> 6) rebased [3] on one merge before, i.e. 63580f669d7f [4], voilà -- it boots!;
>
> And (tadaam!) I have had an idea for a while to replace GCC with LLVM
> (at least for this test), so [0] boots as well!
>
> So, this merge triggered a bug in GCC, seems like... And it's _the_ merge
> commit, which is so-o weird!
I'm not really a compiler person, but IMO it's highly unlikely to be a
GCC bug unless you can point to the bad code generation.
If CONFIG_DEBUG_LIST is triggering it, it's most likely some kind of
memory corruption, in which case seemingly random events can trigger the
detection of it (or lack thereof).
Any chance it boots with the following?
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 348acf2558f3..29e9e3498902 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -84,7 +84,7 @@ static inline __must_check bool check_data_corruption(bool v) { return v; }
if (corruption) { \
if (IS_ENABLED(CONFIG_BUG_ON_DATA_CORRUPTION)) { \
pr_err(fmt, ##__VA_ARGS__); \
- BUG(); \
+ WARN_ON(1); \
} else \
WARN(1, fmt, ##__VA_ARGS__); \
} \
diff --git a/include/linux/list_bl.h b/include/linux/list_bl.h
index ae1b541446c9..395c4f5d8aa6 100644
--- a/include/linux/list_bl.h
+++ b/include/linux/list_bl.h
@@ -25,7 +25,7 @@
#endif
#ifdef CONFIG_DEBUG_LIST
-#define LIST_BL_BUG_ON(x) BUG_ON(x)
+#define LIST_BL_BUG_ON(x) WARN_ON(x)
#else
#define LIST_BL_BUG_ON(x)
#endif
