+Sanitizer folks (BCC'd) (Top of lore thread: https://lore.kernel.org/linux-block/9d0ef355-f430-e8e2-c844-b34cfcf60d88@xxxxxxxxx/) On Fri, Mar 17, 2023 at 11:35 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Mar 17, 2023 at 10:16 AM Jens Axboe <axboe@xxxxxxxxx> wrote: > > > > - blk-mq SRCU fix for BLK_MQ_F_BLOCKING devices (Christ) > > Christ indeed. > > But I think you meant "Chris". > > > Side note - when doing the usual allmodconfig builds with gcc-12 and > > clang before sending them out, for the latter I see this warning being > > spewed with clang-15: > > > > drivers/media/i2c/m5mols/m5mols.o: warning: objtool: m5mols_set_fmt() falls through to next function m5mols_get_frame_desc() > > > > Obviously not related to my changes, but mentioning it in case it has > > been missed as I know you love squeaky clean builds :-). Doesn't happen > > with clang-14. > > Hmm. I have clang-15 too, but I do the allmodconfig builds with gcc, > and only my own "normal config" builds with clang. > > So I don't see this particular issue and my builds are still squeaky clean. > > That said, when I explicitly try that allmodconfig thing with clang, I > can see it too. And the reason seems to be something we've seen > before: UBSAN functions being considered non-return by clang, so clang > generates code like this: > > .... > .LBB24_3: > callq __sanitizer_cov_trace_pc@PLT > movl $2, %esi > movq $.L__unnamed_3, %rdi > callq __ubsan_handle_out_of_bounds > .Lfunc_end24: > .size m5mols_set_fmt, .Lfunc_end24-m5mols_set_fmt > > ie the last thing in that m5mols_set_fmt() function is a call to > __ubsan_handle_out_of_bounds, and then it "falls through" to the next > function. > > And yes, I absolutely *detest* how clang does that. Not only does it > cause objtool sanity checking issues, it fundamentally means that we > can never treat UBSAN warnings as warnings. They are always fatal. > > This is a *huge* clang mis-feature, and I forget what we decided last > that we saw it. > > But I suspect we need to disable UBSAN for clang, because clang gets > this so *horribly* wrong. > > Fatal errors that cannot be recovered from are not something that the > compiler is supposed to decide on. It's exactly the same issue as > BUG() calls: it just results in a dead machine, and in the process the > actual problem easily gets lost (because maybe this only happens while > running X, and no serial console, and no way to actually see what the > UBSAN warning was as a result). > > I really really detest this thing, and I think this is a fatal flaw, > and means that as-is, UBSAN really *has* to be disabled for clang > kernel builds. Maybe that will make somebody wake up and smell the > roses, and stop this idiotic "undefined behavior is fatal" garbage. > > Nick? Do you remember what the fix was last time? > > Linus -- Thanks, ~Nick Desaulniers
