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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux