Thread (10 messages) flat view 10 messages, 2 authors, 2022-03-15

Re: [PATCH 5/5] x86/pkeys: Standardize on u8 for pkey type

From: Ira Weiny <hidden>
Date: 2022-03-15 15:53:55
Also in: lkml

On Mon, Mar 14, 2022 at 04:49:12PM -0700, Dave Hansen wrote:
On 3/10/22 16:57, ira.weiny@intel.com wrote:
quoted
From: Ira Weiny <redacted>

The number of pkeys supported on x86 and powerpc are much smaller than a
u16 value can hold.  It is desirable to standardize on the type for
pkeys.  powerpc currently supports the most pkeys at 32.  u8 is plenty
large for that.

Standardize on the pkey types by changing u16 to u8.
How widely was this intended to "standardize" things?  Looks like it may
have missed a few spots.
Sorry I think the commit message is misleading you.  The justification of u8 as
the proper type is that no arch has a need for more than 255 pkeys.

This specific patch was intended to only change x86.  Per that goal I don't see
any other places in x86 which uses u16 after this patch.

$ git grep u16 arch/x86 | grep key
arch/x86/events/intel/uncore_discovery.c:	const u16 *type_id = key;
arch/x86/include/asm/intel_pconfig.h:	u16 keyid;
arch/x86/include/asm/mmu.h:	u16 pkey_allocation_map;
arch/x86/include/asm/pkeys.h:	u16 all_pkeys_mask = ((1U << arch_max_pkey()) - 1);
Also if we're worried about the type needing to change or with the wrong
type being used, I guess we could just to a pkey_t typedef.
I'm not 'worried' about it.  But I do think it makes the code cleaner and more
self documenting.

Ira
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help