Re: [PATCH 04/11] x86/fpu: eager switch PKRU state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
>>> index 19b137f1b3beb..b184f916319e5 100644
>>> --- a/arch/x86/include/asm/pkeys.h
>>> +++ b/arch/x86/include/asm/pkeys.h
>>> @@ -119,7 +119,7 @@ extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
>>>  		unsigned long init_val);
>>>  extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
>>>  		unsigned long init_val);
>>> -extern void copy_init_pkru_to_fpregs(void);
>>> +extern void pkru_set_init_value(void);
>>
>> Could you elaborate on why the name is being changed?
> 
> The function name read like init_pkru value is copied to fpregs save
> area which is not the case. I could revert it if you prefer.

I would just prefer that we find some way of saying *where* pkru is
being set.  Is it fpstate, fpregs, or both?

>>> +	 * switch between those two operation would load the new value from the
>>> +	 * updated xstate and then we would write (the same value) to the CPU.
>>> +	 */
>>> +	pk->pkru = pkru;
>>> +	__write_pkru(pkru);
>>> +
>>> +}
>>
>> There's an unnecessary line there.
>>
>> This also needs a lot more high-level context about why it is necessary.
>>  I think you had that in the changelog, but we also need the function
>> commented.
> 
> What is necessary? The manual update of "pk->pkru?

Why we need to update fpstate *and* the actual register.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux