unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Lucas A. M. Magalhaes" <lamm@linux.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] Fix tst-pkey expectations on pkey_get
Date: Wed, 12 Feb 2020 13:45:58 -0300	[thread overview]
Message-ID: <158152595856.31885.18040915151106001420@localhost.localdomain> (raw)
In-Reply-To: <87sgjhhzs6.fsf@oldenburg2.str.redhat.com>

> >> Thanks.  Is the patch really correct for 32-bit userspace?
> >> 
> >
> > Thanks for pointing it out. Even in 32-bit mode the mtspr will effect all
> > 64 bits and there is no 32 bit limitation for AMR. I will try to setup
> > a 32 bit userspace machine with pkeys enabled to test this out.
> 
> Thanks.  We may have to tweak the constraints a little bit, though.
> 

Actually there is a problem in this regard we may encounter.  We cannot
ensure that in a context change the upper bits of the GPR will remain
the same. We could either

1. Restrict the usage of the upper pkeys on 32bits.  Maybe the kernel
already restrict already on pkey_alloc.

2. Make it ppc64 specific.

> >> On x86, the hardware has write-disable and read-write-disable flags
> >> instead, which matches the original UAPI interfaces.  This is why no
> >> translation is necessary.
> >
> > Excuse my ignorance. How this translation problem influences the signal
> > handling behaviour?
> 
> The signal handling behavior is just different.  If I recall correctly,
> x86 always resets PKRU to a mostly-disable value, while POWER inherits
> the AMR value from the interrupted thread.  The POWER behavior seems
> more useful to me, but that depends on what the programmer tries to do.
> 

What do you suggest for this.  To change x86 behavior or too change the
test to accept both behaviors?

> I think I have posted x86 patches for changing the behavior, too.
> 

I could not find it.

  reply	other threads:[~2020-02-12 16:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 13:46 [PATCH] Fix tst-pkey expectations on pkey_get Lucas A. M. Magalhaes
2020-02-07 18:22 ` Florian Weimer
2020-02-11 14:03   ` Lucas A. M. Magalhaes
2020-02-11 16:08     ` Florian Weimer
2020-02-12 16:45       ` Lucas A. M. Magalhaes [this message]
2020-02-12 17:17         ` Florian Weimer
2020-02-13 18:41 ` [PATCH V2] " Lucas A. M. Magalhaes
2020-02-14 17:02   ` Florian Weimer
2020-02-14 20:44   ` [PATCH v3] Fix tst-pkey expectations on pkey_get [BZ #23202] Lucas A. M. Magalhaes
2020-02-15 13:12     ` Florian Weimer
2020-02-17 12:09       ` [PATCH v4] " Lucas A. M. Magalhaes
2020-02-17 12:50         ` Florian Weimer
2020-02-19 14:41         ` Tulio Magno Quites Machado Filho

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

  List information: https://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=158152595856.31885.18040915151106001420@localhost.localdomain \
    --to=lamm@linux.ibm.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).