Message ID | 20231115203401.2495875-1-iii@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | kmsan: Enable on s390 | expand |
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > Hi, > > This series provides the minimal support for Kernel Memory Sanitizer on > s390. Kernel Memory Sanitizer is clang-only instrumentation for finding > accesses to uninitialized memory. The clang support for s390 has already > been merged [1]. > > With this series, I can successfully boot s390 defconfig and > debug_defconfig with kmsan.panic=1. The tool found one real > s390-specific bug (fixed in master). > > Best regards, > Ilya Hi Ilya, This is really impressive! Can you please share some instructions on how to run KMSAN in QEMU? I've never touched s390, but I'm assuming it should be possible?
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > KMSAN relies on memblock returning all available pages to it > (see kmsan_memblock_free_pages()). It partitions these pages into 3 > categories: pages available to the buddy allocator, shadow pages and > origin pages. This partitioning is static. > > If new pages appear after kmsan_init_runtime(), it is considered > an error. DEFERRED_STRUCT_PAGE_INIT causes this, so mark it as > incompatible with KMSAN. In the future we could probably collect the deferred pages as well, but it's okay to disable KMSAN for now. > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Alexander Potapenko <glider@google.com>
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > Improve the readability by replacing the custom aligning logic with > ALIGN_DOWN(). Unlike other places where a similar sequence is used, > there is no size parameter that needs to be adjusted, so the standard > macro fits. Good catch, thank you! > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Alexander Potapenko <glider@google.com>
On Thu, 2023-11-16 at 09:42 +0100, Alexander Potapenko wrote: > On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.ibm.com> > wrote: > > > > Hi, > > > > This series provides the minimal support for Kernel Memory > > Sanitizer on > > s390. Kernel Memory Sanitizer is clang-only instrumentation for > > finding > > accesses to uninitialized memory. The clang support for s390 has > > already > > been merged [1]. > > > > With this series, I can successfully boot s390 defconfig and > > debug_defconfig with kmsan.panic=1. The tool found one real > > s390-specific bug (fixed in master). > > > > Best regards, > > Ilya > > Hi Ilya, > > This is really impressive! > Can you please share some instructions on how to run KMSAN in QEMU? > I've never touched s390, but I'm assuming it should be possible? I developed this natively (without cross-compilation or emulation, just KVM), but I just gave the following a try on x86_64 and had some success: $ make LLVM=1 ARCH=s390 O=../linux-build-s390x-cross CC=clang-18 LD=s390x-linux-gnu-ld OBJCOPY=s390x-linux-gnu-objcopy debug_defconfig $ make LLVM=1 ARCH=s390 O=../linux-build-s390x-cross CC=clang-18 LD=s390x-linux-gnu-ld OBJCOPY=s390x-linux-gnu-objcopy menuconfig $ make LLVM=1 ARCH=s390 O=../linux-build-s390x-cross CC=clang-18 LD=s390x-linux-gnu-ld OBJCOPY=s390x-linux-gnu-objcopy -j24 $ qemu-system-s390x -M accel=tcg -smp 2 -m 4G -kernel ../linux-build- s390x-cross/arch/s390/boot/bzImage -nographic -append 'root=/dev/vda1 rw console=ttyS1 nokaslr earlyprintk cio_ignore=all kmsan.panic=1' - object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng- ccw,rng=rng0 It's also possible to get a free s390 machine at [1]. [1] https://linuxone.cloud.marist.edu/oss
Am 16.11.23 um 11:13 schrieb Ilya Leoshkevich: > It's also possible to get a free s390 machine at [1]. > > [1] https://linuxone.cloud.marist.edu/oss I think the URL for registration is this one https://linuxone.cloud.marist.edu/#/register?flag=VM
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > The value assigned to prot is immediately overwritten on the next line > with PAGE_KERNEL. The right hand side of the assignment has no > side-effects. > > Fixes: b073d7f8aee4 ("mm: kmsan: maintain KMSAN metadata for page operations") > Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Alexander Potapenko <glider@google.com> > --- > mm/kmsan/shadow.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c > index b9d05aff313e..2d57408c78ae 100644 > --- a/mm/kmsan/shadow.c > +++ b/mm/kmsan/shadow.c > @@ -243,7 +243,6 @@ int kmsan_vmap_pages_range_noflush(unsigned long start, unsigned long end, > s_pages[i] = shadow_page_for(pages[i]); > o_pages[i] = origin_page_for(pages[i]); > } > - prot = __pgprot(pgprot_val(prot) | _PAGE_NX); > prot = PAGE_KERNEL; This bug dates back to 5.1-rc2, when KMSAN didn't exist upstream. The commit introducing vmap support already had it: https://github.com/google/kmsan/commit/3ff9d7c640d378485286e1a99d85984ae6901f23 I don't remember what exactly required the more relaxed PAGE_KERNEL mask though :)