Messages in this thread | | | Date | Fri, 28 Jan 2022 15:10:16 -0800 | From | Ira Weiny <> | Subject | Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS |
| |
On Fri, Jan 28, 2022 at 02:54:26PM -0800, Dave Hansen wrote: > On 1/27/22 09:54, ira.weiny@intel.com wrote: > > From: Ira Weiny <ira.weiny@intel.com> > > > > Protection Key Supervisor, PKS, is a feature used by kernel code only. > > As such if no kernel users are configured the PKS code is unnecessary > > overhead.
Indeed this was a bit weak sorry. See below.
> > > > Define a Kconfig structure which allows kernel code to detect PKS > > support by an architecture and then subsequently enable that support > > within the architecture. > > > > ARCH_HAS_SUPERVISOR_PKEYS indicates to kernel consumers that an > > architecture supports pkeys. PKS users can then select > > ARCH_ENABLE_SUPERVISOR_PKEYS to turn on the support within the > > architecture. > > > > If ARCH_ENABLE_SUPERVISOR_PKEYS is not selected architectures avoid the > > PKS overhead. > > > > ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first kernel use case > > sets it. > > This is heavy on the "what" and weak on the "why". > > Why isn't this an x86-specific Kconfig? Why do we need two Kconfigs? > Good old user pkeys only has one: > > config ARCH_HAS_PKEYS > bool > > and it's in arch-generic code because there are ppc and x86 > implementations *and* the pkey support touches generic code. > > This might become evident later in the series, but it's clear as mud as > it stands.
Sorry, I'll expand on this.
This issue is that because PKS users are in kernel only and are not part of the architecture specific code there needs to be 2 mechanisms within the Kconfig structure. One to communicate an architectures support PKS such that the user who needs it can depend on that config as well as a second to allow that user to communicate back to the architecture to enable PKS.
Ira
| |