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

On 3/15/22 08:53, Ira Weiny wrote:

On Mon, Mar 14, 2022 at 04:49:12PM -0700, Dave Hansen wrote:

quoted

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);

I was also looking at the generic mm code.

quoted

Also if we're worried about the type needing to changY 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.

Yeah, consistency is good.  Do you mind taking a look at how a pkey_t
would look, and also seeing how much core mm code should use it?