[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfd8e361-9d5b-5b24-08d4-31ad3d392255@intel.com>
Date: Tue, 13 Oct 2020 11:23:08 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: ira.weiny@...el.com, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: Fenghua Yu <fenghua.yu@...el.com>,
Dan Williams <dan.j.williams@...el.com>, x86@...nel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nvdimm@...ts.01.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH RFC V3 3/9] x86/pks: Enable Protection Keys Supervisor
(PKS)
On 10/9/20 12:42 PM, ira.weiny@...el.com wrote:
> +/*
> + * PKS is independent of PKU and either or both may be supported on a CPU.
> + * Configure PKS if the cpu supports the feature.
> + */
Let's at least be consistent about CPU vs. cpu in a single comment. :)
> +static void setup_pks(void)
> +{
> + if (!IS_ENABLED(CONFIG_ARCH_HAS_SUPERVISOR_PKEYS))
> + return;
> + if (!cpu_feature_enabled(X86_FEATURE_PKS))
> + return;
If you put X86_FEATURE_PKS in disabled-features.h, you can get rid of
the explicit CONFIG_ check.
> + cr4_set_bits(X86_CR4_PKS);
> +}
> +
> /*
> * This does the hard work of actually picking apart the CPU stuff...
> */
> @@ -1544,6 +1558,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>
> x86_init_rdrand(c);
> setup_pku(c);
> + setup_pks();
>
> /*
> * Clear/Set all flags overridden by options, need do it
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 6c974888f86f..1b9bc004d9bc 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -822,6 +822,8 @@ config ARCH_USES_HIGH_VMA_FLAGS
> bool
> config ARCH_HAS_PKEYS
> bool
> +config ARCH_HAS_SUPERVISOR_PKEYS
> + bool
>
> config PERCPU_STATS
> bool "Collect percpu memory statistics"
>
Powered by blists - more mailing lists