All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	"Daniel Walker (danielwa)" <danielwa@cisco.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"David Beazley \(dbeazley\)" <dbeazley@cisco.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"xe-linux-external\(mailer list\)" <xe-linux-external@cisco.com>
Subject: Re: mm/debug_vm_pgtable.c:860 warning triggered
Date: Mon, 6 Nov 2023 10:06:03 +0100	[thread overview]
Message-ID: <71d7ba18-8784-4b1c-9797-6fee088fa684@redhat.com> (raw)
In-Reply-To: <87sf5jqutl.fsf@mail.lhotse>

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


WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	"Daniel Walker (danielwa)" <danielwa@cisco.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Cc: "David Beazley (dbeazley)" <dbeazley@cisco.com>,
	"xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: mm/debug_vm_pgtable.c:860 warning triggered
Date: Mon, 6 Nov 2023 10:06:03 +0100	[thread overview]
Message-ID: <71d7ba18-8784-4b1c-9797-6fee088fa684@redhat.com> (raw)
In-Reply-To: <87sf5jqutl.fsf@mail.lhotse>

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



  reply	other threads:[~2023-11-06  9:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-03 23:12 mm/debug_vm_pgtable.c:860 warning triggered Daniel Walker (danielwa)
2023-11-06  3:09 ` Anshuman Khandual
2023-11-06  3:09   ` Anshuman Khandual
2023-11-06  3:22   ` Daniel Walker (danielwa)
2023-11-06  3:22     ` Daniel Walker (danielwa)
2023-11-06  6:06   ` Michael Ellerman
2023-11-06  6:06     ` Michael Ellerman
2023-11-06  9:06     ` David Hildenbrand [this message]
2023-11-06  9:06       ` David Hildenbrand

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=71d7ba18-8784-4b1c-9797-6fee088fa684@redhat.com \
    --to=david@redhat.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=danielwa@cisco.com \
    --cc=dbeazley@cisco.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=xe-linux-external@cisco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.