linux-kernel - Re: [PATCH v5 02/18] mm: Define __pte_leaf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d5e6d897-44f0-413c-bc24-4709896cef55@cs-soprasteria.com>
Date: Tue, 11 Jun 2024 16:53:42 +0000
From: LEROY Christophe <christophe.leroy2@...soprasteria.com>
To: Oscar Salvador <osalvador@...e.de>, Peter Xu <peterx@...hat.com>
CC: Andrew Morton <akpm@...ux-foundation.org>, Jason Gunthorpe
	<jgg@...dia.com>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin
	<npiggin@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v5 02/18] mm: Define __pte_leaf_size() to also take a PMD
 entry



Le 11/06/2024 à 17:08, Oscar Salvador a écrit :
> [Vous ne recevez pas souvent de courriers de osalvador@...e.de. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Tue, Jun 11, 2024 at 10:17:30AM -0400, Peter Xu wrote:
>> Oscar,
>>
>> On Tue, Jun 11, 2024 at 11:34:23AM +0200, Oscar Salvador wrote:
>>> Which means that they would be caught in the following code:
>>>
>>>          ptl = pmd_huge_lock(pmd, vma);
>>>          if (ptl) {
>>>              - 8MB hugepages will be handled here
>>>                  smaps_pmd_entry(pmd, addr, walk);
>>>                  spin_unlock(ptl);
>>>          }
>>>      /* pte stuff */
>>>      ...
>>
>> Just one quick comment: I think there's one challenge though as this is
>> also not a generic "pmd leaf", but a pgtable page underneath.  I think it
>> means smaps_pmd_entry() won't trivially work here, e.g., it will start to
>> do this:
>>
>>        if (pmd_present(*pmd)) {
>>                page = vm_normal_page_pmd(vma, addr, *pmd);
>>
>> Here vm_normal_page_pmd() will only work if pmd_leaf() satisfies its
>> definition as:
>>
>>   * - It should contain a huge PFN, which points to a huge page larger than
>>   *   PAGE_SIZE of the platform.  The PFN format isn't important here.
>>
>> But now it's a pgtable page, containing cont-ptes.  Similarly, I think most
>> pmd_*() helpers will stop working there if we report it as a leaf.
> 
> Heh, I think I managed to confuse myself.
> I do not why but I thought that
> 
>   static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
>   {
>          if (ptep_is_8m_pmdp(mm, addr, ptep))
>               ptep = pte_offset_kernel((pmd_t *)ptep, 0);
>          return ptep_get(ptep);
>   }
> 
> would return the address of the pmd for 8MB hugepages, but it will
> return the address of the first pte?
> 
> Then yeah, this will not work as I thought.
> 
> The problem is that we do not have spare bits for 8xx to mark these ptes
> as cont-ptes or mark them pte as 8MB, so I do not see a clear path on how
> we could remove huge_ptep_get for 8xx.
> 
> I am really curious though how we handle that for THP? Or THP on 8xx
> does not support that size?

8xx doesn't support THP, as far as I know THP is only supported on 
single leaf PMD/PUD, not on cont-PUD/PMD allthough there is some work in 
progress on arm64 to add that.

But honestly I'm not too much interested in 8M transparent pages, what 
I'd like to have first is 512k transparent pages.

Christophe