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

Helge Deller
2023-05-13T12:10:43Z

* Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>:
> 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?

Yes, makes sense.

> [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".

Thanks for bisecting and coming up with a testcase!
The attached patch survives for me on my C3000 with 2GB RAM with this test:
dd if=/dev/zero bs=1896M count=1 | pv
(well, the OOM-killer might jump in, but even that is survived).

Could you try the patch below?

Helge

-

[PATCH] parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag

Fix the __swp_offset() and __swp_entry() macros due to commit 6d239fc78c0b
("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") which introduced the
SWP_EXCLUSIVE flag by reusing the _PAGE_ACCESSED flag.

Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Fixes: 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE")

diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index e2950f5db7c9..522846be54b7 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -413,12 +413,12 @@ extern void paging_init (void);
* For the 64bit version, the offset is extended by 32bit.
*/
#define __swp_type(x) ((x).val & 0x1f)
-#define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
- (((x).val >> 8) & ~0x7) )
+#define __swp_offset(x) ( (((x).val >> 5) & 0x7) | \
+ (((x).val >> 10) << 3) )
#define __swp_entry(type, offset) ((swp_entry_t) { \
((type) & 0x1f) | \
- ((offset & 0x7) << 6) | \
- ((offset & ~0x7) << 8) })
+ ((offset & 0x7) << 5) | \
+ ((offset & ~0x7) << 7) })
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
#define __swp_entry_to_pte(x) ((pte_t) { (x).val })