This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix tst-pkey expectations on pkey_get
* Lucas A. M. Magalhaes:
>> >> 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.
Option 2 is fine with me.
>> >> 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?
For now: Change the test to accept both behaviors.
>> I think I have posted x86 patches for changing the behavior, too.
>>
>
> I could not find it.
It was a kernel patch:
<https://marc.info/?l=linux-mm&m=152526767625176>
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-May/172420.html>
Thanks,
Florian