[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1f74401512ee19176397633aa823f9b6e375973.camel@intel.com>
Date: Mon, 31 Jan 2022 23:10:39 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "hpa@...or.com" <hpa@...or.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"Weiny, Ira" <ira.weiny@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "Yu, Fenghua" <fenghua.yu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V8 16/44] mm/pkeys: Introduce pks_mk_readwrite()
On Thu, 2022-01-27 at 09:54 -0800, ira.weiny@...el.com wrote:
> +void pks_update_protection(int pkey, u32 protection)
> +{
I don't know if this matters too much, but the type of a pkey is either
int or u16 across this series and PKU. But it's only possibly a 4 bit
value. Seems the smallest that would fit is char. Why use one over the
other?
Also, why u32 for protection here? The whole pkrs value containing the
bits for all keys is 32 bits, but per key there is only room ever for 2
bits, right?
It would be nice to be consistent and have a reason, but again, I don't
know if makes any real difference.
Powered by blists - more mailing lists