| Message ID | 20230113171026.582290-5-david@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures with swap PTEs | expand |
On Fri, Jan 13, 2023 at 06:10:04PM +0100, David Hildenbrand wrote: > Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the > offset. This reduces the maximum swap space per file to 64 GiB (was 128 > GiB). > > While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is > defined to be 0 and is rather confusing because we should be dealing > with "Linux PTEs" not "hardware PTEs". Also, properly mask the type in > __swp_entry(). > > Cc: Russell King <linux@armlinux.org.uk> > Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Thanks.
On Fri, Jan 13, 2023 at 06:10:04PM +0100, David Hildenbrand wrote: > Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the > offset. This reduces the maximum swap space per file to 64 GiB (was 128 > GiB). > > While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is > defined to be 0 and is rather confusing because we should be dealing > with "Linux PTEs" not "hardware PTEs". Also, properly mask the type in > __swp_entry(). Today's -next (and at least back to Friday, older logs are unclear - I only noticed -next issues today) fails to NFS boot on an AT91SAM9G20-EK (an old ARMv5 platform) with multi_v5_defconfig, a bisect appears to point to this patch (20aae9eff5acd8f5 in today's -next) as the culprit. The failure happens at some point after starting userspace, the kernel starts spamming the console with messages in the form: get_swap_device: Bad swap file entry 10120d20 repeating the same entry number, though different numbers per boot. The system is booting a Debian userspace and shouldn't have swap configured (I verfified that successful boots don't), though it only has 64M of RAM so there will be some memory pressure, especially during boot. The exact point things fall over seems to vary a little. A sample failing job with the full log is here: https://lava.sirena.org.uk/scheduler/job/262719 Full bisect log: git bisect start # bad: [129af770823407ee115a56c69a04b440fd2fbe61] Add linux-next specific files for 20230206 git bisect bad 129af770823407ee115a56c69a04b440fd2fbe61 # good: [4ec5183ec48656cec489c49f989c508b68b518e3] Linux 6.2-rc7 git bisect good 53b3c6467004c627f42d96ef839b223a749bcdd9 # good: [17b9d0b05d4fa79afb7bd00edb1b97397418a57a] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect good 17b9d0b05d4fa79afb7bd00edb1b97397418a57a # good: [7044a4e1fab22f437d275b1cf85f5c925741276b] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git git bisect good 7044a4e1fab22f437d275b1cf85f5c925741276b # good: [bef6844b00f0c24543d60b79c558f353a43709f1] Merge branch 'staging-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git git bisect good bef6844b00f0c24543d60b79c558f353a43709f1 # good: [f6737c53676f9db99daee069407daf203e75bc0f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock.git git bisect good f6737c53676f9db99daee069407daf203e75bc0f # bad: [05cda97ecb7046f4192a921741aae33b300dd628] mm: factor out a swap_writepage_bdev helper git bisect bad 05cda97ecb7046f4192a921741aae33b300dd628 # good: [ee0800c2f6a9e605947ce499d79fb7e2be16d6dd] mm: convert page_add_anon_rmap() to use a folio internally git bisect good ee0800c2f6a9e605947ce499d79fb7e2be16d6dd # bad: [590a2b5f0a9b740e415e0d52bd8a0f87fc15b87b] ceph: convert ceph_writepages_start() to use filemap_get_folios_tag() git bisect bad 590a2b5f0a9b740e415e0d52bd8a0f87fc15b87b # good: [92644f583d5124b60bc20a3dd21b0bc9142f020c] mm/khugepaged: introduce release_pte_folio() to replace release_pte_page() git bisect good 92644f583d5124b60bc20a3dd21b0bc9142f020c # bad: [cca10df1029373cda5904887544ca6fcbbd2bac7] sh/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE git bisect bad cca10df1029373cda5904887544ca6fcbbd2bac7 # bad: [ad464ff2c0f91fcacc24167fc435aa45fe0b7d1b] m68k/mm: remove dummy __swp definitions for nommu git bisect bad ad464ff2c0f91fcacc24167fc435aa45fe0b7d1b # bad: [20aae9eff5acd8f50f72adca1176f9269a46b827] arm/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE git bisect bad 20aae9eff5acd8f50f72adca1176f9269a46b827 # good: [2321ba3e3733f513e46e29b9c70512ecddbf1085] mm/debug_vm_pgtable: more pte_swp_exclusive() sanity checks git bisect good 2321ba3e3733f513e46e29b9c70512ecddbf1085 # good: [4a446b3dd335d0bd14a5ca3e563688de3637be0c] arc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE git bisect good 4a446b3dd335d0bd14a5ca3e563688de3637be0c # first bad commit: [20aae9eff5acd8f50f72adca1176f9269a46b827] arm/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
On 07.02.23 01:32, Mark Brown wrote: > On Fri, Jan 13, 2023 at 06:10:04PM +0100, David Hildenbrand wrote: >> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the >> offset. This reduces the maximum swap space per file to 64 GiB (was 128 >> GiB). >> >> While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is >> defined to be 0 and is rather confusing because we should be dealing >> with "Linux PTEs" not "hardware PTEs". Also, properly mask the type in >> __swp_entry(). > > Today's -next (and at least back to Friday, older logs are unclear - I > only noticed -next issues today) fails to NFS boot on an AT91SAM9G20-EK > (an old ARMv5 platform) with multi_v5_defconfig, a bisect appears to > point to this patch (20aae9eff5acd8f5 in today's -next) as the culprit. It's been in -next for quite a while, thanks for the report! > > The failure happens at some point after starting userspace, the kernel > starts spamming the console with messages in the form: > > get_swap_device: Bad swap file entry 10120d20 > _swap_info_get() tells us that the swp type seems to be bad. I assume we're dealing with a migration entry, if swap is disabled, and fail to detect is_migration_entry() correctly because the type is messed up. Could you give the following a test? From 8c4bdbd9862f85782d5919d044c172b584063e83 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david@redhat.com> Date: Wed, 8 Feb 2023 15:08:01 +0100 Subject: [PATCH] arm/mm: Fix swp type masking in __swp_entry() We're masking with the number of type bits instead of the type mask, which is obviously wrong. Fixes: 20aae9eff5ac ("arm/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: David Hildenbrand <david@redhat.com> --- arch/arm/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h index 2e626e6da9a3..a58ccbb406ad 100644 --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -292,7 +292,7 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) #define __swp_type(x) (((x).val >> __SWP_TYPE_SHIFT) & __SWP_TYPE_MASK) #define __swp_offset(x) ((x).val >> __SWP_OFFSET_SHIFT) -#define __swp_entry(type, offset) ((swp_entry_t) { (((type) & __SWP_TYPE_BITS) << __SWP_TYPE_SHIFT) | \ +#define __swp_entry(type, offset) ((swp_entry_t) { (((type) & __SWP_TYPE_MASK) << __SWP_TYPE_SHIFT) | \ ((offset) << __SWP_OFFSET_SHIFT) }) #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
On Wed, Feb 08, 2023 at 03:12:06PM +0100, David Hildenbrand wrote: > On 07.02.23 01:32, Mark Brown wrote: > > Today's -next (and at least back to Friday, older logs are unclear - I > > only noticed -next issues today) fails to NFS boot on an AT91SAM9G20-EK > > (an old ARMv5 platform) with multi_v5_defconfig, a bisect appears to > > point to this patch (20aae9eff5acd8f5 in today's -next) as the culprit. > It's been in -next for quite a while, thanks for the report! Yeah, there's been some other things obscuring the issue. > Could you give the following a test? > > > From 8c4bdbd9862f85782d5919d044c172b584063e83 Mon Sep 17 00:00:00 2001 > From: David Hildenbrand <david@redhat.com> > Date: Wed, 8 Feb 2023 15:08:01 +0100 > Subject: [PATCH] arm/mm: Fix swp type masking in __swp_entry() > > We're masking with the number of type bits instead of the type mask, which > is obviously wrong. Tested-by: Mark Brown <broonie@kernel.org> but note that I had to manually apply it, though it's pretty trivial so I probably applied the right thing.
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index 92abd4cd8ca2..ce543cd9380c 100644 --- a/arch/arm/include/asm/pgtable-2level.h +++ b/arch/arm/include/asm/pgtable-2level.h @@ -126,6 +126,9 @@ #define L_PTE_SHARED (_AT(pteval_t, 1) << 10) /* shared(v6), coherent(xsc3) */ #define L_PTE_NONE (_AT(pteval_t, 1) << 11) +/* We borrow bit 7 to store the exclusive marker in swap PTEs. */ +#define L_PTE_SWP_EXCLUSIVE L_PTE_RDONLY + /* * These are the memory types, defined to be compatible with * pre-ARMv6 CPUs cacheable and bufferable bits: n/a,n/a,C,B diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h index eabe72ff7381..106049791500 100644 --- a/arch/arm/include/asm/pgtable-3level.h +++ b/arch/arm/include/asm/pgtable-3level.h @@ -76,6 +76,9 @@ #define L_PTE_NONE (_AT(pteval_t, 1) << 57) /* PROT_NONE */ #define L_PTE_RDONLY (_AT(pteval_t, 1) << 58) /* READ ONLY */ +/* We borrow bit 7 to store the exclusive marker in swap PTEs. */ +#define L_PTE_SWP_EXCLUSIVE (_AT(pteval_t, 1) << 7) + #define L_PMD_SECT_VALID (_AT(pmdval_t, 1) << 0) #define L_PMD_SECT_DIRTY (_AT(pmdval_t, 1) << 55) #define L_PMD_SECT_NONE (_AT(pmdval_t, 1) << 57) diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h index f049072b2e85..886c275995a2 100644 --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -271,27 +271,48 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) } /* - * Encode and decode a swap entry. Swap entries are stored in the Linux - * page tables as follows: + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that + * are !pte_none() && !pte_present(). + * + * Format of swap PTEs: * * 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 * 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 - * <--------------- offset ------------------------> < type -> 0 0 + * <------------------- offset ------------------> E < type -> 0 0 + * + * E is the exclusive marker that is not stored in swap entries. * - * This gives us up to 31 swap files and 128GB per swap file. Note that + * This gives us up to 31 swap files and 64GB per swap file. Note that * the offset field is always non-zero. */ #define __SWP_TYPE_SHIFT 2 #define __SWP_TYPE_BITS 5 #define __SWP_TYPE_MASK ((1 << __SWP_TYPE_BITS) - 1) -#define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT) +#define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT + 1) #define __swp_type(x) (((x).val >> __SWP_TYPE_SHIFT) & __SWP_TYPE_MASK) #define __swp_offset(x) ((x).val >> __SWP_OFFSET_SHIFT) -#define __swp_entry(type,offset) ((swp_entry_t) { ((type) << __SWP_TYPE_SHIFT) | ((offset) << __SWP_OFFSET_SHIFT) }) +#define __swp_entry(type, offset) ((swp_entry_t) { (((type) & __SWP_TYPE_BITS) << __SWP_TYPE_SHIFT) | \ + ((offset) << __SWP_OFFSET_SHIFT) }) #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) }) -#define __swp_entry_to_pte(swp) __pte((swp).val | PTE_TYPE_FAULT) +#define __swp_entry_to_pte(swp) __pte((swp).val) + +#define __HAVE_ARCH_PTE_SWP_EXCLUSIVE +static inline int pte_swp_exclusive(pte_t pte) +{ + return pte_isset(pte, L_PTE_SWP_EXCLUSIVE); +} + +static inline pte_t pte_swp_mkexclusive(pte_t pte) +{ + return set_pte_bit(pte, __pgprot(L_PTE_SWP_EXCLUSIVE)); +} + +static inline pte_t pte_swp_clear_exclusive(pte_t pte) +{ + return clear_pte_bit(pte, __pgprot(L_PTE_SWP_EXCLUSIVE)); +} /* * It is an error for the kernel to have more swap files than we can
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the offset. This reduces the maximum swap space per file to 64 GiB (was 128 GiB). While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is defined to be 0 and is rather confusing because we should be dealing with "Linux PTEs" not "hardware PTEs". Also, properly mask the type in __swp_entry(). Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: David Hildenbrand <david@redhat.com> --- arch/arm/include/asm/pgtable-2level.h | 3 +++ arch/arm/include/asm/pgtable-3level.h | 3 +++ arch/arm/include/asm/pgtable.h | 35 +++++++++++++++++++++------ 3 files changed, 34 insertions(+), 7 deletions(-)