Re: i386: selftests: vm: compaction_test: BUG: kernel NULL pointer dereference, address: 00000000

[Peter Xu]

Hi, Naresh,

On Sun, Apr 12, 2020 at 12:24:57PM +0530, Naresh Kamboju wrote:
> On Linux mainline kernel 5.6.0 running kselftest vm compaction_test on i386
>  kernel running on x86_64 devices we have noticed this Kernel BUG followed by
> Kernel panic.
> 
> BUG: kernel NULL pointer dereference, address: 00000000
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> 
> Steps to reproduce:
> --------------------------
> # cd /opt/kselftests/default-in-kernel/vm/
> # ./compaction_test
> 
> [   45.955706] kauditd_printk_skb: 15 callbacks suppressed
> [   45.955707] audit: type=1334 audit(1586671685.974:25): prog-id=13 op=UNLOAD
> [   45.968082] audit: type=1334 audit(1586671685.974:26): prog-id=12 op=UNLOAD
> [   46.008163] get_swap_device: Bad swap file entry 7007504a
> [   46.013647] BUG: kernel NULL pointer dereference, address: 00000000

I suspect this is the same issue with:

20200410002518.GG8179@shao2-debian/">https://lore.kernel.org/lkml/20200410002518.GG8179@shao2-debian/

And since this one is very easy to reproduce, I finally noticed that
we have wrongly enabled uffd-wp on x86_32, which is definely not going
to work... Because we'll use bit 2 of swap entry assuming that's the
uffd-wp bit, while that's part of swp offset on 32bit systems.

Naresh, could you try whether below change fixes the issue for you?

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8d078642b4be..7ac524d1316e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -149,7 +149,7 @@ config X86
        select HAVE_ARCH_TRACEHOOK
        select HAVE_ARCH_TRANSPARENT_HUGEPAGE
        select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD if X86_64
-       select HAVE_ARCH_USERFAULTFD_WP         if USERFAULTFD
+       select HAVE_ARCH_USERFAULTFD_WP         if X86_64 && USERFAULTFD
        select HAVE_ARCH_VMAP_STACK             if X86_64
        select HAVE_ARCH_WITHIN_STACK_FRAMES
        select HAVE_ASM_MODVERSIONS

Thanks,

-- 
Peter Xu