On Fri, Mar 17, 2023 at 11:59:11AM -0700, Nick Desaulniers wrote: > +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: > > > 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. I've hit these cases a few times too. The __ubsan_handle_* stuff is designed to be recoverable. I think there are some cases where we're tripping over Clang bugs, though. Some of the past issues have been with Clang thinking some UBSAN feature was trap-only (e.g. -fsanitizer=local-bounds), but here it actually generated the call, but decided it was no-return. *sigh* > > But I suspect we need to disable UBSAN for clang, because clang gets > > this so *horribly* wrong. Which is to say, it normally gets it right, but there are some instances where things go weird. If it was horribly wrong, there would be a LOT more objtool warnings. :) I'm not opposed to disabling UBSAN for all*config builds if we need to, but I want to get these Clang bugs found and fixed so I'd be sad to lose the coverage. -- Kees Cook
