powerpc: fix pgtable pmd cache init

Nicholas Piggin <npiggin@gmail.com> writes:

> Commit 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
> mixed up PMD_INDEX_SIZE and PMD_CACHE_INDEX a couple of times. This
> resulted in 64s/hash/4k configs to panic at boot with a false positive
> error check.
>
> Fix that and simplify error handling by moving the check to the caller.
>
> Fixes: 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

I did another fix here.

https://lkml.kernel.org/r/20161214043349.23677-1-aneesh.kumar@linux.vnet.ibm.com

But this patch makes it much simpler. Hence.

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

There is this hunk in the patch I did.


> ---
>  arch/powerpc/mm/hugetlbpage.c |  6 +-----
>  arch/powerpc/mm/init-common.c | 11 +++--------
>  2 files changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 289df38fb7e0..f21f6b907d99 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -810,12 +810,8 @@ static int __init hugetlbpage_init(void)
>  		 * if we have pdshift and shift value same, we don't
>  		 * use pgt cache for hugepd.
>  		 */
> -		if (pdshift > shift) {
> +		if (pdshift > shift)
>  			pgtable_cache_add(pdshift - shift, NULL);
> -			if (!PGT_CACHE(pdshift - shift))
> -				panic("hugetlbpage_init(): could not create "
> -				      "pgtable cache for %d bit pagesize\n", shift);
> -		}
>  #if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_8xx)
>  		else if (!hugepte_cache) {
>  			/*
> diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
> index a175cd82ae8c..1a3be5ae1d07 100644
> --- a/arch/powerpc/mm/init-common.c
> +++ b/arch/powerpc/mm/init-common.c
> @@ -80,6 +80,8 @@ void pgtable_cache_add(unsigned shift, void (*ctor)(void *))
>  	new = kmem_cache_create(name, table_size, align, 0, ctor);
>  	kfree(name);
>  	pgtable_cache[shift - 1] = new;
> +	if (!new)
> +		panic("Could not allocate pgtable cache for order %d", shift);
>  	pr_debug("Allocated pgtable cache for order %d\n", shift);
>  }
>
> @@ -88,7 +90,7 @@ void pgtable_cache_init(void)
>  {
>  	pgtable_cache_add(PGD_INDEX_SIZE, pgd_ctor);
>
> -	if (PMD_INDEX_SIZE && !PGT_CACHE(PMD_INDEX_SIZE))
> +	if (PMD_CACHE_INDEX && !PGT_CACHE(PMD_CACHE_INDEX))
>  		pgtable_cache_add(PMD_CACHE_INDEX, pmd_ctor);
>  	/*
>  	 * In all current configs, when the PUD index exists it's the
> @@ -97,11 +99,4 @@ void pgtable_cache_init(void)
>  	 */
>  	if (PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE))
>  		pgtable_cache_add(PUD_INDEX_SIZE, pud_ctor);
> -
> -	if (!PGT_CACHE(PGD_INDEX_SIZE))
> -		panic("Couldn't allocate pgd cache");
> -	if (PMD_INDEX_SIZE && !PGT_CACHE(PMD_INDEX_SIZE))
> -		panic("Couldn't allocate pmd pgtable caches");
> -	if (PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE))
> -		panic("Couldn't allocate pud pgtable caches");
>  }
> -- 
> 2.11.0

On Wed, 04 Jan 2017 07:34:41 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > Commit 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
> > mixed up PMD_INDEX_SIZE and PMD_CACHE_INDEX a couple of times. This
> > resulted in 64s/hash/4k configs to panic at boot with a false positive
> > error check.
> >
> > Fix that and simplify error handling by moving the check to the caller.
> >
> > Fixes: 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
> > Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> > Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > Cc: Scott Wood <oss@buserror.net>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>  
> 
> I did another fix here.
> 
> https://lkml.kernel.org/r/20161214043349.23677-1-aneesh.kumar@linux.vnet.ibm.com
> 
> But this patch makes it much simpler. Hence.
> 
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> 
> There is this hunk in the patch I did.

Ah, I missed that. My patch just fixes the 9b081e10805cd bug, but this
hunk looks like it should still go in as another patch. Will you resend
it?

Thanks,
Nick


> 
> --- a/arch/powerpc/include/asm/book3s/64/hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash.h
> @@ -33,9 +33,9 @@
> 				 H_PUD_INDEX_SIZE + H_PGD_INDEX_SIZE + PAGE_SHIFT)
>  #define H_PGTABLE_RANGE		(ASM_CONST(1) << H_PGTABLE_EADDR_SIZE)
> 
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) &&  defined(CONFIG_PPC_64K_PAGES)
>  /*
> - * only with hash we need to use the second half of pmd page table
> + * only with hash 64k we need to use the second half of pmd page table
>   * to store pointer to deposited pgtable_t
>   */
>  #define H_PMD_CACHE_INDEX	(H_PMD_INDEX_SIZE + 1)
>

Nicholas Piggin <npiggin@gmail.com> writes:

> On Wed, 04 Jan 2017 07:34:41 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> 
>> > Commit 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
>> > mixed up PMD_INDEX_SIZE and PMD_CACHE_INDEX a couple of times. This
>> > resulted in 64s/hash/4k configs to panic at boot with a false positive
>> > error check.
>> >
>> > Fix that and simplify error handling by moving the check to the caller.
>> >
>> > Fixes: 9b081e10805cd ("powerpc: port 64 bits pgtable_cache to 32 bits")
>> > Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>> > Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> > Cc: Scott Wood <oss@buserror.net>
>> > Cc: linuxppc-dev@lists.ozlabs.org
>> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>  
>> 
>> I did another fix here.
>> 
>> https://lkml.kernel.org/r/20161214043349.23677-1-aneesh.kumar@linux.vnet.ibm.com
>> 
>> But this patch makes it much simpler. Hence.
>> 
>> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> 
>> There is this hunk in the patch I did.
>
> Ah, I missed that. My patch just fixes the 9b081e10805cd bug, but this
> hunk looks like it should still go in as another patch. Will you resend
> it?
>

ok will do that.

-aneesh