Re: [PATCH 0/9] [v3] System Calls for Memory Protection Keys

From: Andy Lutomirski
Date: Thu Jun 30 2016 - 13:40:42 EST


On Thu, Jun 30, 2016 at 9:46 AM, Dave Hansen <dave@xxxxxxxx> wrote:
> On 06/30/2016 02:41 AM, Ingo Molnar wrote:
>> * Dave Hansen <dave@xxxxxxxx> wrote:
>>> Are there any concerns with merging these into the x86 tree so
>>> that they go upstream for 4.8? The updates here are pretty
>>> minor.
>>
>>> include/linux/pkeys.h | 39 +-
>>> include/uapi/asm-generic/mman-common.h | 5 +
>>> include/uapi/asm-generic/unistd.h | 12 +-
>>> mm/mprotect.c | 134 +-
>>
>> So I'd love to have some high level MM review & ack for these syscall ABI
>> extensions.
>
> That's a quite reasonable request, but I'm really surprised by it at
> this point. The proposed ABI is one very straightforward extension to
> one existing system call, plus four others that you personally suggested.
>

I apologize for the very late review, but (see other thread) I think
we may need to make sure we've defined the signal delivery semantics
in a useful way before enabling these. I'm not convinced that the
current behavior is helpful. This may or may not require any change
to the syscall signatures, but I can imagine that doing it right would
involve adding another syscall to *read* the current signal-delivery
state of a pkey or perhaps of all the pkeys. That could potentially
be achieved by adding an extra pointer parameter to pkey_get so
pkey_get can return both the current state and the state at next
signal delivery.

--Andy