On Thu, 2023-11-16 at 15:55 +0100, Alexander Potapenko wrote:

On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich [off-list ref]
wrote:

quoted

Avoid false KMSAN negatives with SLUB_DEBUG by allowing
kmsan_slab_free() to poison the freed memory, and by preventing
init_object() from unpoisoning new allocations.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
 mm/kmsan/hooks.c | 2 +-
 mm/slub.c        | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c
index 7b5814412e9f..7a30274b893c 100644
--- a/mm/kmsan/hooks.c
+++ b/mm/kmsan/hooks.c

@@ -76,7 +76,7 @@ void kmsan_slab_free(struct kmem_cache *s, void

*object)
                return;

        /* RCU slabs could be legally used after free within the
RCU period */
-       if (unlikely(s->flags & (SLAB_TYPESAFE_BY_RCU |
SLAB_POISON)))
+       if (unlikely(s->flags & SLAB_TYPESAFE_BY_RCU))
                return;
        /*
         * If there's a constructor, freed memory must remain in
the same state

diff --git a/mm/slub.c b/mm/slub.c
index 63d281dfacdb..8d9aa4d7cb7e 100644
--- a/mm/slub.c
+++ b/mm/slub.c

@@ -1024,7 +1024,8 @@ static __printf(3, 4) void slab_err(struct

kmem_cache *s, struct slab *slab,
        add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
 }

-static void init_object(struct kmem_cache *s, void *object, u8
val)
+__no_sanitize_memory static void

__no_sanitize_memory should be used with great care, because it drops
all instrumentation from the function, and any shadow writes will be
lost.
Won't it be better to add kmsan_poison() to init_object() if you want
it to stay uninitialized?

I wanted to avoid a ping-pong here, in which we already have properly
poisoned memory, then memset() incorrectly unpoisons it, and then we
undo the damage. My first attempt involved using __memset() instead,
but this resulted in worse assembly code. I wish there were something
like memset_noinstr().

Right now init_object() doesn't seem to be doing anything besides these
memset()s, but this can of course change in the future. So I don't mind
using kmsan_poison() instead of __no_sanitize_memory here too much,
since it results in better maintainability.