[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181029063626.GD128403@gmail.com>
Date: Mon, 29 Oct 2018 07:36:26 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Daniel Micay <danielmicay@...il.com>
Cc: Andy Lutomirski <luto@...capital.net>,
Dave Hansen <dave.hansen@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
kernel list <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Michael Ellerman <mpe@...erman.id.au>,
Will Deacon <will.deacon@....com>,
Andy Lutomirski <luto@...nel.org>, jroedel@...e.de
Subject: Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()
* Daniel Micay <danielmicay@...il.com> wrote:
> > I suppose we could add a new flag for pkey_get() or something.
>
> That would work, since I can apply the workaround (disabling the
> feature in child processes) if I get EINVAL. The flag wouldn't need to
> do anything, just existing and being tied to this patch so I have a
> way to detect that I can safely use MPK after fork.
A new flag for the pkey_alloc() syscall, right?
Thanks,
Ingo
Powered by blists - more mailing lists