Re: mm/debug_vm_pgtable.c:860 warning triggered

Re: mm/debug_vm_pgtable.c:860 warning triggered

[Anshuman Khandual]

Hello Daniel,

This test just ensures that PFN is preserved during pte <--> swap pte transformations
, and the warning here seems to have been caused by powerpc platform specific helpers
and/or its pte_t representation. Adding powerpc folks and platform mailing list here.

- Anshuman

On 11/4/23 04:42, Daniel Walker (danielwa) wrote:
> 
> Hi,
> 
> This warning has triggered on our powerpc equipment.
> 
> debug_vm_pgtable: [debug_vm_pgtable         ]: Validating architecture page table helpers
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:860 0xc1012190
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 6.6.0 #14
> Hardware name: MPC8544DS e500v2 0x80210030 MPC8544 DS
> NIP:  c1012190 LR: c101216c CTR: 00000000
> REGS: c145bc70 TRAP: 0700   Not tainted  (6.6.0)
> MSR:  00029000 <CE,EE,ME>  CR: 48000248  XER: 00000000
> 
> GPR00: c1012094 c145bd60 c1498000 c145bd6c 0000003c 00000000 7cffffff 00000001 
> GPR08: efa2d000 00000000 00000000 2d589a6c 88000248 00000000 c000343c 00000000 
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c10000d8 
> GPR24: 00000000 00000000 00000000 00000000 00000000 00000200 fffffffc 7cffffff 
> Call Trace:
> [c145bd60] [c1012094] 0xc1012094 (unreliable)
> [c145be30] [c0003044] 0xc0003044
> [c145bea0] [c1000ea0] 0xc1000ea0
> [c145bee0] [c0003460] 0xc0003460
> [c145bf00] [c0011224] 0xc0011224
> --- interrupt: 0 at 0x00000000
> NIP:  00000000 LR: 00000000 CTR: 00000000
> REGS: c145bf10 TRAP: 0000   Not tainted  (6.6.0)
> MSR:  00000000 <>  CR: 00000000  XER: 00000000
> 
> GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> --- interrupt: 0
> Code: 3861000c 38a00000 4b10a235 8121000c 7c1f4800 41820008 0fe00000 8121006c 7d29e378 5529463e 7c1d4840 41820008 <0fe00000> 81410080 2c0affff 41820058 
> ---[ end trace 0000000000000000 ]---
> 
> This appears to be the following code,
> 
>  850 
>  851 static void __init pte_swap_tests(struct pgtable_debug_args *args)
>  852 {
>  853         swp_entry_t swp;
>  854         pte_t pte;
>  855 
>  856         pr_debug("Validating PTE swap\n");
>  857         pte = pfn_pte(args->fixed_pte_pfn, args->page_prot);
>  858         swp = __pte_to_swp_entry(pte);
>  859         pte = __swp_entry_to_pte(swp);
>  860         WARN_ON(args->fixed_pte_pfn != pte_pfn(pte));
>  861 }
>  862 
> 
> 
> This only happens in powerpc with the following config options enabled,
> 
> CONFIG_PTE_64BIT=y
> CONFIG_PHYS_64BIT=y
> 
> These options can increase the pte_t type to 64bits, which swp_entry_t remains unsigned
> long which is 32 bits on there systems. This warning appears to have triggered since the
> inclusion of CONFIG_DEBUG_VM_PGTABLE support for powerpc.
> 
> To reproduce the issue you can use the attached config to build a powerpc kernel. Then
> boot with QEMU using the following command line.
> 
> qemu-system-ppc -M mpc8544ds -kernel ../powerpc/vmlinux -append "console=ttyS0" -nographic
> 
> Please CC me on any fixes in the future.
> 
> Thanks,
> 
> Daniel
> 

Re: mm/debug_vm_pgtable.c:860 warning triggered

[Daniel Walker (danielwa)]

On Mon, Nov 06, 2023 at 08:39:26AM +0530, Anshuman Khandual wrote:
> Hello Daniel,
> 
> This test just ensures that PFN is preserved during pte <--> swap pte transformations
> , and the warning here seems to have been caused by powerpc platform specific helpers
> and/or its pte_t representation. Adding powerpc folks and platform mailing list here.
> 
> - Anshuman
> 

How is the swap support to work if the pte_t is 64bits but the swp_entry_t is 32bits?
I would think there's other platforms which do this.

Daniel

Re: mm/debug_vm_pgtable.c:860 warning triggered

[Michael Ellerman]

Anshuman Khandual <anshuman.khandual@arm.com> writes:
> Hello Daniel,
>
> This test just ensures that PFN is preserved during pte <--> swap pte transformations
> , and the warning here seems to have been caused by powerpc platform specific helpers
> and/or its pte_t representation. Adding powerpc folks and platform mailing list here.

Doesn't the test need a similar treatment to:

  2321ba3e3733 ("mm/debug_vm_pgtable: more pte_swp_exclusive() sanity checks")

Which said:
    Especially, the pfn_pte() is dodgy when the swap PTE layout differs
    heavily from ordinary PTEs.  Let's properly construct a swap PTE from swap
    type+offset.


cheers

Re: mm/debug_vm_pgtable.c:860 warning triggered

[David Hildenbrand]

On 06.11.23 07:06, Michael Ellerman wrote:
> Anshuman Khandual <anshuman.khandual@arm.com> writes:
>> Hello Daniel,
>>
>> This test just ensures that PFN is preserved during pte <--> swap pte transformations
>> , and the warning here seems to have been caused by powerpc platform specific helpers
>> and/or its pte_t representation. Adding powerpc folks and platform mailing list here.
> 

32bit swp_entry_t with 64bit pte is supported by making sure that we 
never store a swap offset larger than what we can actually fit into the 
swp_entry_t.

There is common code in place to handle that: see 
generic_max_swapfile_size(), which does to conversion back and forth to 
see how many bits of the offset actually survive the conversion.

> Doesn't the test need a similar treatment to:
> 
>    2321ba3e3733 ("mm/debug_vm_pgtable: more pte_swp_exclusive() sanity checks")
> 
> Which said:
>      Especially, the pfn_pte() is dodgy when the swap PTE layout differs
>      heavily from ordinary PTEs.  Let's properly construct a swap PTE from swap
>      type+offset.


Sounds reasonable to me.

-- 
Cheers,

David / dhildenb