* Christoph Biedl <linux-kernel.bfrz@xxxxxxxxxxxxxxxxxx>: > 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@xxxxxxxxxx> > 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@xxxxxxxxxx > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > Cc: "James E.J. Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Cc: Helge Deller <deller@xxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxx> 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 })
