[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201017054216.GB3702775@iweiny-DESK2.sc.intel.com>
Date: Fri, 16 Oct 2020 22:42:16 -0700
From: Ira Weiny <ira.weiny@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Fenghua Yu <fenghua.yu@...el.com>, x86@...nel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.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 5/9] x86/pks: Add PKS kernel API
On Fri, Oct 16, 2020 at 01:07:47PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:54PM -0700, ira.weiny@...el.com wrote:
> > +static inline void pks_update_protection(int pkey, unsigned long protection)
> > +{
> > + current->thread.saved_pkrs = update_pkey_val(current->thread.saved_pkrs,
> > + pkey, protection);
> > + preempt_disable();
> > + write_pkrs(current->thread.saved_pkrs);
> > + preempt_enable();
> > +}
>
> write_pkrs() already disables preemption itself. Wrapping it in yet
> another layer is useless.
I was thinking the update to saved_pkrs needed this protection as well and that
was to be included in the preemption disable. But that too is incorrect.
I've removed this preemption disable.
Thanks,
Ira
Powered by blists - more mailing lists