linux-kernel - Re: [PATCH 1/6] powerpc: port 64 bits pgtable

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: <df8b5a70-e705-e282-c33c-0c0b93d6b72e@c-s.fr>
Date:	Sun, 14 Aug 2016 20:51:44 +0200
From:	christophe leroy <christophe.leroy@....fr>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Scott Wood <oss@...error.net>
Cc:	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] powerpc: port 64 bits pgtable_cache to 32 bits

Le 14/08/2016 à 16:17, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@....fr> writes:
>
>> Today powerpc64 uses a set of pgtable_caches while powerpc32 uses
>> standard pages when using 4k pages and a single pgtable_cache
>> if using other size pages. In addition powerpc32 uses another cache
>> when handling huge pages.
>>
>> In preparation of implementing huge pages on the 8xx, this patch
>> replaces the specific powerpc32 handling by the 64 bits approach.
>
> Why is this needed ? Can you also summarize the page size used and the
> hugepage format you are planning to use ? . What are the page sizes
> supported by 8xx ? Also is the new code copy of existing powerpc64 4k
> page size code ?

8xx supports two huge page sizes: 8M and 512k.
As PGD entries points on 4M page tables, it means we are in an 
eterogenous situation:
1/ when using 8M huge pages, we are in the same situation as what is 
done for the BOOK3S (which supports 16M, 256M and 1G), that is several 
PDG entries pointing to a single PTE entry.
2/ when using 512k huge pages, we are in the same situation as whan is 
done for the BOOK3E: a PGD entry points to the hugepage table that 
handles several huge pages (in our case 8 huge pages)

The code from init_64 have been moved to a new file named init-common in 
order to be used by init_32 too.
The code from the 64 bits .h has been copied into the 32 bits .h (indeed 
it's been copied twice as the .h are now duplicated into nohash and 
book3s versions)

[...]

>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index 7372ee1..9164a77 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
>>  #ifdef CONFIG_PPC_FSL_BOOK3E
>>  	int i;
>>  	int num_hugepd = 1 << (pshift - pdshift);
>> -	cachep = hugepte_cache;
>> +	cachep = PGT_CACHE(1);
>>  #else
>>  	cachep = PGT_CACHE(pdshift - pshift);
>>  #endif
>
> Can you explain the usage of PGT_CACHE(1) ?

[...]

>
> I still didn't quiet follow why we are replacing
>
>  -	hugepte_cache =  kmem_cache_create("hugepte-cache", sizeof(pte_t),
>  -					   HUGEPD_SHIFT_MASK + 1, 0, NULL);
>  +	pgtable_cache_add(1, NULL);
>

Euh ... Indeed I wanted something to replace hugepte_cache. But it looks 
like it should be something like PGT_CACHE(0) for 32 bits targets having 
32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs. 
But PGT_CACHE(0) doesn't exist (yet).

Looking once more, that might not really be needed I think. I'll rework 
it and see what I can achieve.

Christophe

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus