diff options
| author |  Alexander Potapenko <glider@google.com>
| 2024-01-24 18:31:34 +0100 |
|---|---|---|
| committer |  Andrew Morton <akpm@linux-foundation.org>
| 2024-02-22 10:24:41 -0800 |
| commit | d749cc7547bb46be73da848576ea155daf8186f3 (patch) | |
| tree | 000dac1d786fef35069720ce4d55f23d65e97b99 /mm/memcontrol.c | |
| parent | highmem: add kernel-doc for memcpy_*_folio() (diff) | |
| download | linux-d749cc7547bb46be73da848576ea155daf8186f3.tar.gz linux-d749cc7547bb46be73da848576ea155daf8186f3.tar.bz2 linux-d749cc7547bb46be73da848576ea155daf8186f3.zip | |
mm: kmsan: remove runtime checks from kmsan_unpoison_memory()
Similarly to what's been done in commit 85716a80c16d ("kmsan: allow using
__msan_instrument_asm_store() inside runtime"), it should be safe to call
kmsan_unpoison_memory() from within the runtime, as it does not allocate
memory or take locks. Remove the redundant runtime checks.
This should fix false positives seen with CONFIG_DEBUG_LIST=y when
the non-instrumented lib/stackdepot.c failed to unpoison the memory
chunks later checked by the instrumented lib/list_debug.c
Also replace the implementation of kmsan_unpoison_entry_regs() with
a call to kmsan_unpoison_memory().
Link: https://lkml.kernel.org/r/20240124173134.1165747-1-glider@google.com
Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core")
Signed-off-by: Alexander Potapenko <glider@google.com>
Tested-by: Marco Elver <elver@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Nicholas Miehlbradt <nicholas@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'mm/memcontrol.c')
0 files changed, 0 insertions, 0 deletions