Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"

[Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

Helge Deller wrote...

> Since you run the 32-bit kernel, huge-pages are not involved as they
> aren't available in the 32-bit kernels.
> So I think swapping is triggering it.
> You could try to find a test program which triggers swapping, e.g. LTS testcases?
> Another test could be to enable CONFIG_MIGRATION again and disable
> all swap spaces and see if it survives.

Well, turns out I'm not using swap at all. But the "memory under
pressure" seemed right, and I could easily trigger the crash by
allowcating almost the entire available memory[1].

Then bisecting led to

commit 6d239fc78c0b0c687e5408573350714e6e789d71
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Jan 13 18:10:16 2023 +0100

    parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

    Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused
    _PAGE_ACCESSED location in the swap PTE.  Looking at pte_present() and
    pte_none() checks, there seems to be no actual reason why we cannot use
    it: we only have to make sure we're not using _PAGE_PRESENT.

    Reusing this bit avoids having to steal one bit from the swap offset.

    Link: https://lkml.kernel.org/r/20230113171026.582290-17-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
    Cc: Helge Deller <deller@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Does this make sense?

    Christoph

[1] Total is 1 Gbyte, and running
    | dd if=/dev/zero bs=896M count=1 | pv --rate-limit=1k >/dev/null
    might not be the best style but does the trick: Wait for pv to
    count up to a minute, then ^C it. If the host is still okay after
    that, it's considered "good".

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]