On Fri, Aug 21, 2020 at 2:39 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Aug 21, 2020 at 12:57 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > Look, four stores into memset(), yeah that's a bit weird. I didn't think > > you meant "four" literally. But in any case, that has nothing to do with > > the topic at hand. It would be just as bad if it was a 16-byte structure > > being initialized with an out-of-line memset() call. > > Actually, I mis-remembered. It wasn't four stores. > > It was two. > > We have this lovely "sas_ss_reset()" function that initializes three > fields in a structure (two to zero, one to '2'). > > And we used it in a critical place that didn't allow function calls > (because we have magic rules with the SMAP instructions). > > And clang turned the initalization into a memset(). Which then > triggered our "you can't do that here" check on the generated code. > > This is the kind of special rules we sometimes can have for code > generation, where the compiler really doesn't understand that no, you > can't just replace this code sequence with a function call, because > there are things going on around it that really mean that the code > should be generated the way we wrote it. For more context for folks at home eating popcorn and enjoying the show: https://github.com/ClangBuiltLinux/linux/issues/876#issuecomment-613049480. And that was specifically with KASAN enabled and doesn't appear to be common behavior in clang otherwise (higher threshold). Why the heuristics change for when it seems to be more profitable to roll assignment of contiguous members of the same struct to the same value into a memset, and 2 longs seems to be the threshold for KASAN, I don't know. But I agree that should be fixed on the compiler side, which is why I haven't been pushing the kernel workaround. Everyone's just too busy right now; folks working on kernel sanitizers have their hands full with KCSAN or MTE (on armv8.5) or default initialization, and I'm trying to keep the build green (ie. this series, well the v2 below, and https://lore.kernel.org/lkml/20200812004308.1448603-1-nivedita@xxxxxxxxxxxx/ would be much appreciated), and get ready for plumbers, and wrap up my intern's project, and do yearly performance reviews at my day job, and million other things. I've filed https://bugs.llvm.org/show_bug.cgi?id=47280 to discuss more the ability to opt into builtins from a freestanding environment. Now that Arvind has provided an excellent analysis of how the builtin functionality works (bookmarked: https://lore.kernel.org/lkml/20200821172935.GA1411923@xxxxxxxxxxxxxxxxxx/), were there still objections to add the -fno-builtin-stpcpy flags for clang to the Makefile? I would like to get https://lore.kernel.org/lkml/20200819191654.1130563-1-ndesaulniers@xxxxxxxxxx/T/#m76c445f9645f62bc6ffc48ca26949725235688a0 landed so the build is not red for another week. -- Thanks, ~Nick Desaulniers
