From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Thu, 17 May 2018 12:11:15 +0200 Message-ID: <9c7b1c17-5c0e-11aa-0803-a0f503087b37@redhat.com> References: <57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net> <6286ba0a-7e09-b4ec-e31f-bd091f5940ff@redhat.com> <20180503021058.GA5670@ram.oc3035372033.ibm.com> <927c8325-4c98-d7af-b921-6aafcf8fe992@redhat.com> <314e1a48-db94-9b37-8793-a95a2082c9e2@redhat.com> <20180516203534.GA5479@ram.oc3035372033.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180516203534.GA5479@ram.oc3035372033.ibm.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Ram Pai Cc: linux-arch , Linux-MM , Linux API , X86 ML , Dave Hansen , linux-x86_64@vger.kernel.org, Andy Lutomirski , linuxppc-dev List-Id: linux-api@vger.kernel.org On 05/16/2018 10:35 PM, Ram Pai wrote: > So let me see if I understand the overall idea. > > Application can allocate new keys through a new syscall > sys_pkey_alloc_1(flags, init_val, sig_init_val) > > 'sig_init_val' is the permission-state of the key in signal context. I would keep the existing system call and just add a flag, say PKEY_ALLOC_SETSIGNAL. If the current thread needs different access rights, it can set those rights just after pkey_alloc returns. There is no race that matters here, I think. Thanks, Florian