On 05/19/2018 03:50 AM, Andy Lutomirski wrote:
Now another thread calls pkey_alloc(), so UAMR is asynchronously changed, and the thread will write zero to the relevant AMR bits. If I understand correctly, this means that the decision to mask off unallocated keys via UAMR effectively forces the initial value of newly-allocated keys in other threads in the allocating process to be zero, whatever zero means. (I didn't get far enough in the POWER docs to figure out what zero means.) So
(Note that this belongs on the other thread, here I originally wanted to talk about the lack of reset of AMR to the default value on execve.)
I don't think UAMOR is updated asynchronously. On pkey_alloc, it is only changed for the current thread, and future threads launched from it. Existing threads are unaffected. This still results in a programming model which is substantially different from x86.
I don't think you're doing anyone any favors by making UAMR dynamic.
This is still true, I think. Thanks, Florian
