On Sat, 26 Apr 2025 at 10:42, Linus Torvalds <torva...@linux-foundation.org> wrote: > > We had something similar some time ago, where there was a drm > assertion without error handling, which caused the compiler to see > that there was a static path where the invalid value was used, and > then caused other problems. I forget the details, and gmail search > isn't helping me
My dim memories came back and helped me with the right search terms, and this is what I was talking about: https://lore.kernel.org/all/CAHk-=wg4etks+pguco4gdrrxt+1ubbfgqtpoqsxlszvvawp...@mail.gmail.com/ different compiler, very different results, but same kind of issue: warning about an error case without actually *dealing* with the error, which results in the compiler seeing a static code path from the warning to an invalid situation, and causing odd problems. Please people: "ASSERT()" like behavior is simply not acceptable in the kernel. WARN_ON() and friends need to either be otherwise benign (ie "warn but then continue to do valid things") or they need to be *handled* (ie "warn and then refuse to do things that aren't valid"). Just warning and then doing random crap is not sane. If you aren't capable of dealing with the situation, don't do the bogus test. Just warning about it isn't fixing the code, and can make things actively worse as in these two examples. But I do think that clang needs to stop doing that "make things actively worse" part. Maybe even have an actual honest-to-goodness "this is a static undefined situation, I will stop generating code AND THAT MEANS I FAIL THE BUILD". Not this silent "now I generate random code by falling through to something else entirely" that clang does now. Not good. Linus
