NR_VALID_PKRU_BITS/PKRU_VALID_MASK are never used after it was
introduced. So better to remove them.
Signed-off-by: Alex Shi <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: [email protected]
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Pankaj Bharadiya <[email protected]>
Cc: Aubrey Li <[email protected]>
Cc: [email protected]
---
arch/x86/kernel/fpu/xstate.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index fa31470bbf24..73c3e2e72a88 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -899,8 +899,6 @@ const void *get_xsave_field_ptr(int xfeature_nr)
#ifdef CONFIG_ARCH_HAS_PKEYS
-#define NR_VALID_PKRU_BITS (CONFIG_NR_PROTECTION_KEYS * 2)
-#define PKRU_VALID_MASK (NR_VALID_PKRU_BITS - 1)
/*
* This will go out and modify PKRU register to set the access
* rights for @pkey to @init_val.
--
1.8.3.1
On Tue, Jan 21, 2020 at 04:50:11PM +0800, Alex Shi wrote:
> NR_VALID_PKRU_BITS/PKRU_VALID_MASK are never used after it was
> introduced. So better to remove them.
Dave moved them in so while they are not used indeed better to
get approve from him (to be sure they were not reserved for
future development).
Initial commit 8459429693395ca9e8d18101300b120ad9171795
On 1/21/20 3:43 AM, Cyrill Gorcunov wrote:
> On Tue, Jan 21, 2020 at 04:50:11PM +0800, Alex Shi wrote:
>> NR_VALID_PKRU_BITS/PKRU_VALID_MASK are never used after it was
>> introduced. So better to remove them.
> Dave moved them in so while they are not used indeed better to
> get approve from him (to be sure they were not reserved for
> future development).
>
> Initial commit 8459429693395ca9e8d18101300b120ad9171795
FWIW, I'm not a massive fan of blindly removing stuff like this. Maybe
it's better to remove the cruft, but it's even better to try to figure
out why I might have added them in the first place. :)
I *think* it was an attempt to ensure that a resulting PKRU value can be
written to PKRU, independent of the type it was stored as.
Let me see if I can come up with something nicer than ripping these out.
On Tue, Jan 21, 2020 at 03:07:23PM -0800, Dave Hansen wrote:
> FWIW, I'm not a massive fan of blindly removing stuff like this. Maybe
> it's better to remove the cruft, but it's even better to try to figure
> out why I might have added them in the first place. :)
>
> I *think* it was an attempt to ensure that a resulting PKRU value can be
> written to PKRU, independent of the type it was stored as.
>
> Let me see if I can come up with something nicer than ripping these out.
Sure. Thanks a huge, Dave!