[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o867gowq.ffs@tglx>
Date: Fri, 26 Nov 2021 12:03:01 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: ira.weiny@...el.com, Dave Hansen <dave.hansen@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>
Cc: Ira Weiny <ira.weiny@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Fenghua Yu <fenghua.yu@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev,
linux-mm@...ck.org
Subject: Re: [PATCH V7 05/18] x86/pks: Add PKS setup code
On Thu, Nov 25 2021 at 16:15, Thomas Gleixner wrote:
> On Tue, Aug 03 2021 at 21:32, ira weiny wrote:
> Aside of that, the function which set's up the init value is really
> bogus. As you explained in the cover letter a kernel user has to:
>
> 1) Claim an index in the enum
> 2) Add a default value to the array in that function
>
> Seriously? How is that any better than doing:
>
> #define PKS_KEY0_DEFAULT PKR_RW_ENABLE
> #define PKS_KEY1_DEFAULT PKR_ACCESS_DISABLE
> ...
> #define PKS_KEY15_DEFAULT PKR_ACCESS_DISABLE
>
> and let the compiler construct pkrs_init_value?
>
> TBH, it's not and this function has to be ripped out in case that you
> need a dynamic allocation of keys some day. So what is this buying us
> aside of horrible to read and utterly pointless code?
And as Taoyi confirmed its broken.
It surely takes a reviewer to spot that and an external engineer to run
rdmsr -a to validate that this is not working as expected, right?
Sigh...
Powered by blists - more mailing lists