All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linux-api@vger.kernel.org, dave.hansen@intel.com,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Mon, 12 Nov 2018 11:29:17 +0100	[thread overview]
Message-ID: <87bm6utwqq.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181108192226.GC5481@ram.oc3035372033.ibm.com> (Ram Pai's message of "Thu, 8 Nov 2018 11:22:26 -0800")

* Ram Pai:

> On Thu, Nov 08, 2018 at 01:05:09PM +0100, Florian Weimer wrote:
>> Would it be possible to reserve a bit for PKEY_DISABLE_READ?
>> 
>> I think the POWER implementation can disable read access at the hardware
>> level, but not write access, and that cannot be expressed with the
>> current PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE bits.
>
> POWER hardware can disable-read and can **also disable-write**
> at the hardware level. It can disable-execute aswell at the
> hardware level.   For example if the key bits for a given key in the AMR
> register is  
> 	0b01  it is read-disable
> 	0b10  it is write-disable
>
> To support access-disable, we make the key value 0b11.
>
> So in case if you want to know if the key is read-disable 'bitwise-and' it
> against 0x1.  i.e  (x & 0x1)

Not sure if we covered that alreay, but my problem is that I cannot
translate a 0b01 mask to a PKEY_DISABLE_* flag combination with the
current flags.  0b10 and 0b11 are fine.

POWER also loses the distinction between PKEY_DISABLE_ACCESS and
PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE, but that's fine.  This breaks
the current glibc test case, but I have a patch for that.  Arguably, the
test is wrong or at least overly strict in what it accepts.

Thanks,
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linux-api@vger.kernel.org, linux-mm@kvack.org,
	dave.hansen@intel.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Mon, 12 Nov 2018 11:29:17 +0100	[thread overview]
Message-ID: <87bm6utwqq.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181108192226.GC5481@ram.oc3035372033.ibm.com> (Ram Pai's message of "Thu, 8 Nov 2018 11:22:26 -0800")

* Ram Pai:

> On Thu, Nov 08, 2018 at 01:05:09PM +0100, Florian Weimer wrote:
>> Would it be possible to reserve a bit for PKEY_DISABLE_READ?
>> 
>> I think the POWER implementation can disable read access at the hardware
>> level, but not write access, and that cannot be expressed with the
>> current PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE bits.
>
> POWER hardware can disable-read and can **also disable-write**
> at the hardware level. It can disable-execute aswell at the
> hardware level.   For example if the key bits for a given key in the AMR
> register is  
> 	0b01  it is read-disable
> 	0b10  it is write-disable
>
> To support access-disable, we make the key value 0b11.
>
> So in case if you want to know if the key is read-disable 'bitwise-and' it
> against 0x1.  i.e  (x & 0x1)

Not sure if we covered that alreay, but my problem is that I cannot
translate a 0b01 mask to a PKEY_DISABLE_* flag combination with the
current flags.  0b10 and 0b11 are fine.

POWER also loses the distinction between PKEY_DISABLE_ACCESS and
PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE, but that's fine.  This breaks
the current glibc test case, but I have a patch for that.  Arguably, the
test is wrong or at least overly strict in what it accepts.

Thanks,
Florian

  reply	other threads:[~2018-11-12 10:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 12:05 pkeys: Reserve PKEY_DISABLE_READ Florian Weimer
2018-11-08 14:57 ` Dave Hansen
2018-11-08 15:01   ` Florian Weimer
2018-11-08 17:14     ` Dave Hansen
2018-11-08 17:37       ` Florian Weimer
2018-11-08 20:12         ` Ram Pai
2018-11-08 20:12           ` Ram Pai
2018-11-08 20:23           ` Florian Weimer
2018-11-08 20:23             ` Florian Weimer
2018-11-09 18:09             ` Ram Pai
2018-11-09 18:09               ` Ram Pai
2018-11-12 12:00               ` Florian Weimer
2018-11-12 12:00                 ` Florian Weimer
2018-11-27 10:23                 ` Ram Pai
2018-11-27 10:23                   ` Ram Pai
2018-11-27 11:57                   ` Florian Weimer
2018-11-27 11:57                     ` Florian Weimer
2018-11-27 15:31                     ` Dave Hansen
2018-11-27 15:31                       ` Dave Hansen
2018-11-29 11:37                       ` Florian Weimer
2018-11-29 11:37                         ` Florian Weimer
2018-12-03  4:02                         ` Ram Pai
2018-12-03  4:02                           ` Ram Pai
2018-12-03 15:52                           ` Florian Weimer
2018-12-03 15:52                             ` Florian Weimer
2018-12-04  6:23                             ` Ram Pai
2018-12-04  6:23                               ` Ram Pai
2018-12-05 13:00                               ` Florian Weimer
2018-12-05 13:00                                 ` Florian Weimer
2018-12-05 20:23                                 ` Ram Pai
2018-12-05 20:23                                   ` Ram Pai
2018-12-05 16:21                           ` Andy Lutomirski
2018-12-05 16:21                             ` Andy Lutomirski
2018-12-05 20:36                             ` Ram Pai
2018-12-05 20:36                               ` Ram Pai
2018-11-08 20:08       ` Ram Pai
2018-11-08 20:11         ` Dave Hansen
2018-11-08 20:14         ` Florian Weimer
2018-11-08 19:22 ` Ram Pai
2018-11-08 19:22   ` Ram Pai
2018-11-12 10:29   ` Florian Weimer [this message]
2018-11-12 10:29     ` 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=87bm6utwqq.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dave.hansen@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.