linux-kernel - Re: [RFC PATCH v2 11/20] powerpc/mm: Complement huge_pte

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]

Date: Sat, 25 May 2024 06:44:06 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Oscar Salvador <osalvador@...e.de>
CC: Andrew Morton <akpm@...ux-foundation.org>, Jason Gunthorpe
	<jgg@...dia.com>, Peter Xu <peterx@...hat.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: [RFC PATCH v2 11/20] powerpc/mm: Complement huge_pte_alloc() for
 all non HUGEPD setups



Le 25/05/2024 à 06:29, Oscar Salvador a écrit :
> On Fri, May 17, 2024 at 09:00:05PM +0200, Christophe Leroy wrote:
>> huge_pte_alloc() for non-HUGEPD targets is reserved for 8xx at the
>> moment. In order to convert other targets for non-HUGEPD, complement
>> huge_pte_alloc() to support any standard cont-PxD setup.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
>> ---
>>   arch/powerpc/mm/hugetlbpage.c | 25 ++++++++++++++++++++++++-
>>   1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index 42b12e1ec851..f8aefa1e7363 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -195,11 +195,34 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
>>   pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
>>   		      unsigned long addr, unsigned long sz)
>>   {
>> -	pmd_t *pmd = pmd_off(mm, addr);
>> +	pgd_t *pgd;
>> +	p4d_t *p4d;
>> +	pud_t *pud;
>> +	pmd_t *pmd;
>> +
>> +	addr &= ~(sz - 1);
>> +	pgd = pgd_offset(mm, addr);
>> +
>> +	p4d = p4d_offset(pgd, addr);
>> +	if (sz >= PGDIR_SIZE)
>> +		return (pte_t *)p4d;
>> +
>> +	pud = pud_alloc(mm, p4d, addr);
>> +	if (!pud)
>> +		return NULL;
>> +	if (sz >= PUD_SIZE)
>> +		return (pte_t *)pud;
>> +
>> +	pmd = pmd_alloc(mm, pud, addr);
>> +	if (!pmd)
>> +		return NULL;
>>   
>>   	if (sz < PMD_SIZE)
>>   		return pte_alloc_huge(mm, pmd, addr, sz);
>>   
>> +	if (!IS_ENABLED(CONFIG_PPC_8xx))
>> +		return (pte_t *)pmd;
> 
> So only 8xx has cont-PMD for hugepages?

No, all have cont-PMD but only 8xx handles pages greater than PMD_SIZE 
as cont-PTE instead of cont-PMD.

> 
>> +
>>   	if (sz != SZ_8M)
>>   		return NULL;
> 
> Since this function is the core for allocation huge pages, I think it would
> benefit from a comment at the top explaining the possible layouts.
> e.g: Who can have cont-{P4d,PUD,PMD} etc.
> A brief explanation of the possible scheme for all powerpc platforms.

All is standard except 8xx, let's just have a comment for 8xx.

> 
> That would help people looking into this in a future.
> 
>   
>