[PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit

Kumar Gala galak at kernel.crashing.org
Tue Nov 29 03:01:06 EST 2011


On Nov 24, 2011, at 6:43 PM, Benjamin Herrenschmidt wrote:

> On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
> 
> .../...
> 
>> #ifdef CONFIG_PPC_MM_SLICES
>> -	psize = mmu_get_tsize(get_slice_psize(mm, ea));
>> -	tsize = mmu_get_psize(psize);
>> +	psize = get_slice_psize(mm, ea);
>> +	tsize = mmu_get_tsize(psize);
>> 	shift = mmu_psize_defs[psize].shift;
>> #else
>> -	vma = find_vma(mm, ea);
>> -	psize = vma_mmu_pagesize(vma);	/* returns actual size in bytes */
>> -	asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (psize));
>> -	shift = 31 - lz;
>> -	tsize = 21 - lz;
>> +	psize = vma_mmu_pagesize(find_vma(mm, ea));
>> +	shift = __ilog2(psize);
>> +	tsize = shift - 10;
>> #endif
> 
> Now, I know it was already there and you are just moving it around in
> this patch but come on ... find_vma() here ? Really ? And with no result
> checking nor boundary checking (remember it can return a vma that
> doesn't enclose the address etc....). Now I know in this specific case
> it -should- be safe but still...
> 
> Now, the caller is just doing:
> 
> 	book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
> 
> So why not just change the prototype and pass the vma down instead ?

Can we do this on top of the patchset instead of changing the existing patchset?

- k


More information about the Linuxppc-dev mailing list