[RFC v7 15/25] powerpc: Program HPTE key protection bits

Michael Ellerman mpe at ellerman.id.au
Thu Oct 19 16:12:15 AEDT 2017


Ram Pai <linuxram at us.ibm.com> writes:
> On Wed, Oct 18, 2017 at 06:15:40PM +0200, Laurent Dufour wrote:
>> On 31/07/2017 02:12, Ram Pai wrote:
>> > diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
>> > index 1ded6df..4b7e3f4 100644
>> > --- a/arch/powerpc/include/asm/pkeys.h
>> > +++ b/arch/powerpc/include/asm/pkeys.h
>> > @@ -72,6 +72,19 @@ static inline int vma_pkey(struct vm_area_struct *vma)
>> >  #define AMR_RD_BIT 0x1UL
>> >  #define AMR_WR_BIT 0x2UL
>> >  #define IAMR_EX_BIT 0x1UL
>> > +
>> > +static inline u64 pte_to_hpte_pkey_bits(u64 pteflags)
>> > +{
>> > +	if (!pkey_inited)
>> > +		return 0x0UL;
>> 
>> Why making such a check here, is it to avoid the following check during the
>> boot process only ?
>> IIUC, there is no way to get H_PAGE_PKEY_BIT* set when pkey_inited is false.
>
> I know its a little paronia. Trying to avoid a case where the
> uninitialized pkey bits in the pte are erroneously interpreted as valid
> by this function. Remember that the caller of this function will use the
> return value to program the hpte. Nothing really bad should happen
> since none of the keys are enabled. But ... just playing it safe.

I think that's probably over-paranoid. It's not like it adds much
overhead, but it is a hot path, so no need to make it slower than it
needs to be.

cheers


More information about the Linuxppc-dev mailing list