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

[Helge Deller <deller@gmx.de>]

* 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 })