Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1434439 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/9] [v3] System Calls for Memory Protection Keys Ingo Molnar <mingo@kernel.org> - 2016-06-30 12:50 +0200
    Re: [PATCH 0/9] [v3] System Calls for Memory Protection Keys Dave Hansen <dave@sr71.net> - 2016-06-30 18:50 +0200
      Re: [PATCH 0/9] [v3] System Calls for Memory Protection Keys Andy Lutomirski <luto@amacapital.net> - 2016-06-30 19:50 +0200

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

* Dave Hansen <dave@sr71.net> 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.

Thanks,

	Ingo

[toc] | [next] | [standalone]

#1434738

On 06/30/2016 02:41 AM, Ingo Molnar wrote:
> * Dave Hansen <dave@sr71.net> 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.

They haven't *changed* since last November:

	http://lkml.iu.edu/hypermail/linux/kernel/1511.2/00985.html

I see you added Mel and Hugh to the cc.  Is that who you'd like to see
review it?  Is there anyone else?  I'd expect Mel and Hugh's review time
to be highly contended, and I'd rather not gate these on them.

If it helps anyone review these more easily, I've html-ized the affected
manpages and published them:

	https://www.sr71.net/~dave/intel/manpages/

[toc] | [prev] | [next] | [standalone]

#1434764

On Thu, Jun 30, 2016 at 9:46 AM, Dave Hansen <dave@sr71.net> wrote:
> On 06/30/2016 02:41 AM, Ingo Molnar wrote:
>> * Dave Hansen <dave@sr71.net> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web