On 3/17/23 12:35?PM, Linus Torvalds 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". Oops yes indeed, good catch. Though I'd love to think that if we did have a resurrection of that nature, blk-mq would be high on the list of things to hack on. >> 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. I just do both to avoid anything odd, it's just a few min each. > 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. Gotcha, thanks for digging into that. I must admit I didn't look any further at it, but figured it was worth reporting... -- Jens Axboe
