From: David Hildenbrand <david@redhat.com>
To: Helge Deller <deller@gmx.de>,
Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Cc: linux-parisc@vger.kernel.org
Subject: Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
Date: Sat, 13 May 2023 15:21:05 +0200 [thread overview]
Message-ID: <8d23bbd1-adcb-d52e-791b-42faae04c14e@redhat.com> (raw)
In-Reply-To: <ZF9+OYqQS/vy7Oq5@p100>
> 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?
Thanks for debugging! :)
>
> 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 })
This fix makes it work like the layout I documented.
What I originally tried doing was reusing one of the spare bits instead of reworking
the layout. Apparently, I got the old layout wrong. :(
So if I understood the layout right this time, maybe we can just use one of the two
spare bits: _PAGE_HUGE (or alternatively, _PAGE_DIRTY_BIT)?
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index e2950f5db7c9..ee9f08cd5938 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -218,8 +218,8 @@ extern void __update_cache(pte_t pte);
#define _PAGE_KERNEL_RWX (_PAGE_KERNEL_EXEC | _PAGE_WRITE)
#define _PAGE_KERNEL (_PAGE_KERNEL_RO | _PAGE_WRITE)
-/* We borrow bit 23 to store the exclusive marker in swap PTEs. */
-#define _PAGE_SWP_EXCLUSIVE _PAGE_ACCESSED
+/* We borrow bit 21 to store the exclusive marker in swap PTEs. */
+#define _PAGE_SWP_EXCLUSIVE _PAGE_HUGE
/* The pgd/pmd contains a ptr (in phys addr space); since all pgds/pmds
* are page-aligned, we don't care about the PAGE_OFFSET bits, except
@@ -405,7 +405,7 @@ extern void paging_init (void);
*
* 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- * <---------------- offset -----------------> P E <ofs> < type ->
+ * <---------------- offset ---------------> E P <ofs> 0 < type ->
*
* E is the exclusive marker that is not stored in swap entries.
* _PAGE_PRESENT (P) must be 0.
diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 110a36479dce..7510db355f48 100644
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-05-13 13:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 17:56 Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!" Christoph Biedl
2023-05-10 20:29 ` Helge Deller
2023-05-11 17:22 ` Christoph Biedl
2023-05-11 17:35 ` Helge Deller
2023-05-12 21:56 ` Christoph Biedl
2023-05-13 12:10 ` Helge Deller
2023-05-13 13:21 ` David Hildenbrand [this message]
2023-05-13 13:58 ` Helge Deller
2023-05-13 23:32 ` David Hildenbrand
2023-05-14 0:09 ` Helge Deller
2023-05-13 16:24 ` Christoph Biedl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d23bbd1-adcb-d52e-791b-42faae04c14e@redhat.com \
--to=david@redhat.com \
--cc=deller@gmx.de \
--cc=linux-kernel.bfrz@manchmal.in-ulm.de \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox