On Tue, Oct 11, 2022 at 3:20 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Oct 8, 2022 at 1:21 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Alexander Potapenko (43): > > crypto: kmsan: disable accelerated configs under KMSAN > > Ok, so this conflicted pretty badly with the crypto tree having > re-organized their Kconfig files. Sorry about that. There was a fix for this problem: https://lore.kernel.org/lkml/20220909095811.2166073-2-glider@xxxxxxxxxx/, but I am not sure where it ended up, given that crypto tree didn't have KMSAN, and -mm didn't have the crypto changes. > I channelled my inner Alexander the Great, and just cut the whole > thing through by disabling all the architecture-accelerated crypto > includes when KMSAN was enabled. That's exactly the point. Thanks for doing that! > But that's very different from your tree that disabled the options > individually, so some KMSAN person should probably look around at it > and decide whether some more subtle approach is called for. No, in fact it was pretty painful to disable the configs one by one. Thankfully, the new Kconfig layout simplifies the things for us. > The other thing I notice from just doing a build is that I now get > > vmlinux.o: warning: objtool: kasan_report+0x12: call to > stackleak_track_stack() with UACCESS enabled Guess that's unrelated to KMSAN. Happy to take a look anyway. > which may just be a "need to teach objtool this is ok", but I'm not > seeing why it's now starting to happen. Maybe just code generation > changed for some reason, or maybe it's just that config options ended > up changing enough to expose this on my allmodconfig builds. > > Cc'ing people who may know better. > > This is just my reaction from doing the merge and test-build. There > may or may not be more commentary once I've actually tried to boot > into this thing. > > Linus Small nit: - Dmitry Vyukov introduces KMSAN: the Kernel Memory Sanitizer. It uses clang-generated instrumentation to detect used-unintialized bugs down to the single bit level. s/Dmitry Vyukov/Alexander Potapenko/ ;) (although contributions of Dmitry Vyukov and Marco Elver to the whole thing cannot be underestimated!). -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
