Re: [PATCH v4 11/45] kmsan: add KMSAN runtime core

[Alexander Potapenko]

On Sat, Jul 2, 2022 at 2:18 AM Hillf Danton <hdanton@xxxxxxxx> wrote:
>
> On Fri,  1 Jul 2022 16:22:36 +0200 Alexander Potapenko wrote:
> > +
> > +bool kmsan_internal_is_module_addr(void *vaddr)
> > +{
> > +     return ((u64)vaddr >=3D MODULES_VADDR) && ((u64)vaddr < MODULES_END);
> > +}
> > +
> > +bool kmsan_internal_is_vmalloc_addr(void *addr)
> > +{
> > +     return ((u64)addr >=3D VMALLOC_START) && ((u64)addr < VMALLOC_END);
> > +}
>
> Given is_vmalloc_addr(), feel free to add a one-line comment showing the
> reason for adding the kmsan internal version.

Ok, will do. I'm also going to move these two to mm/kmsan/kmsan.h, so
that they can be inlined.
Keeping internal versions allows us to not have these two functions
instrumented by KMSAN, which gains us some performance and (more
importantly) prevents potential recursion.

In fact right now the original is_vmalloc_addr() doesn't contain
instrumented memory accesses and is thus safe to be called from KMSAN
runtime without causing recursion.
I am not sure though whether we can rely on that remaining true, so I
added it along with the internal version of is_module_address(), which
actually has the problem.

> Hillf




--
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