Re: [GIT PULL] MM updates for 6.1-rc1

[Alexander Potapenko]

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