linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Florian Weimer <fweimer@redhat.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Linux-MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-x86_64@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>,
	".linuxppc-dev"@lists.ozlabs.org
Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
Date: Wed, 2 May 2018 19:10:58 -0700	[thread overview]
Message-ID: <20180503021058.GA5670@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <CALCETrW_Dt-HoG4keFJd8DSD=tvyR+bBCFrBDYdym4GQbfng4A@mail.gmail.com>

On Wed, May 02, 2018 at 09:23:49PM +0000, Andy Lutomirski wrote:
> 
> > If I recall correctly, the POWER maintainer did express a strong desire
> > back then for (what is, I believe) their current semantics, which my
> > PKEY_ALLOC_SIGNALINHERIT patch implements for x86, too.
> 
> Ram, I really really don't like the POWER semantics.  Can you give some
> justification for them?  Does POWER at least have an atomic way for
> userspace to modify just the key it wants to modify or, even better,
> special load and store instructions to use alternate keys?

I wouldn't call it POWER semantics. The way I implemented it on power
lead to the semantics, given that nothing was explicitly stated 
about how the semantics should work within a signal handler.

As far as power ISA is concerned, there are no special load
and store instructions that can somehow circumvent the permissions
of the key associated with the PTE.

Also unlike x86;  on POWER, pkey-permissions are not administered based
on its run context (user context, signal context).
Hence the default behavior tends to make the key permissions remain the
same regardless of the context.


> Does POWER at least have an atomic way for userspace to modify just the 
> key it wants to modify .. ?

No. just like PKRU, on power its a register which has bits corresponding
to each key. Entire register has to be read and written, which means
multiple keys could get modified in the same write.


adding ppc mailing list to the CC.

> 
> --Andy

-- 
Ram Pai

  parent reply	other threads:[~2018-05-03  2:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02 13:26 [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Florian Weimer
2018-05-02 14:30 ` Dave Hansen
2018-05-02 15:12   ` Florian Weimer
2018-05-02 15:28     ` Dave Hansen
2018-05-02 21:08       ` Florian Weimer
2018-05-02 22:03         ` Dave Hansen
2018-05-07  9:47           ` Florian Weimer
2018-05-02 17:09     ` Andy Lutomirski
2018-05-02 17:17       ` Florian Weimer
2018-05-02 20:41         ` Andy Lutomirski
2018-05-02 21:06           ` Florian Weimer
2018-05-02 21:23             ` Andy Lutomirski
2018-05-02 22:08               ` Dave Hansen
2018-05-02 22:22                 ` Andy Lutomirski
2018-05-02 22:32                   ` Dave Hansen
2018-05-02 23:32                     ` Andy Lutomirski
2018-05-02 23:58                       ` Dave Hansen
2018-05-03  1:14                         ` Andy Lutomirski
2018-05-03 14:42                           ` Dave Hansen
2018-05-03 14:42                           ` Florian Weimer
2018-05-03  2:10               ` Ram Pai [this message]
2018-05-03  4:05                 ` Andy Lutomirski
2018-05-07  9:48                   ` Florian Weimer
2018-05-08  2:49                     ` Andy Lutomirski
2018-05-08 12:40                       ` Florian Weimer
2018-05-09 14:41                         ` Andy Lutomirski
2018-05-14 12:01                           ` Florian Weimer
2018-05-14 15:32                             ` Andy Lutomirski
2018-05-14 15:34                               ` Florian Weimer
2018-05-16 17:01                                 ` Dave Hansen
2018-05-16 20:52                             ` Ram Pai
2018-05-16 20:54                               ` Andy Lutomirski
2018-05-16 20:35                         ` Ram Pai
2018-05-16 20:37                           ` Andy Lutomirski
2018-05-16 21:07                             ` Ram Pai
2018-05-17 10:09                               ` Florian Weimer
2018-05-17 10:11                           ` Florian Weimer
2018-05-03 14:37               ` Florian Weimer
2018-05-02 21:12     ` Ram Pai
2018-05-02 21:18       ` Andy Lutomirski
2018-05-02 23:38         ` Ram Pai
2018-05-07  9:47           ` Florian Weimer
2018-05-07  9:43         ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180503021058.GA5670@ram.oc3035372033.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=".linuxppc-dev"@lists.ozlabs.org \
    --cc=dave.hansen@intel.com \
    --cc=fweimer@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-x86_64@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).