On 06/04/2018 09:02 PM, Ram Pai wrote:
On Mon, Jun 04, 2018 at 07:57:46PM +0200, Florian Weimer wrote:
On 06/04/2018 04:01 PM, Ram Pai wrote:
On Mon, Jun 04, 2018 at 12:12:07PM +0200, Florian Weimer wrote:
On 06/03/2018 10:18 PM, Ram Pai wrote:
On Mon, May 21, 2018 at 01:29:11PM +0200, Florian Weimer wrote:
On 05/20/2018 09:11 PM, Ram Pai wrote:
Florian,
Does the following patch fix the problem for you? Just like x86
I am enabling all keys in the UAMOR register during
initialization itself. Hence any key created by any thread at
any time, will get activated on all threads. So any thread
can change the permission on that key. Smoke tested it
with your test program.
I think this goes in the right direction, but the AMR value after
fork is still strange:
AMR (PID 34912): 0x0000000000000000
AMR after fork (PID 34913): 0x0000000000000000
AMR (PID 34913): 0x0000000000000000
Allocated key in subprocess (PID 34913): 2
Allocated key (PID 34912): 2
Setting AMR: 0xffffffffffffffff
New AMR value (PID 34912): 0x0fffffffffffffff
About to call execl (PID 34912) ...
AMR (PID 34912): 0x0fffffffffffffff
AMR after fork (PID 34914): 0x0000000000000003
AMR (PID 34914): 0x0000000000000003
Allocated key in subprocess (PID 34914): 2
Allocated key (PID 34912): 2
Setting AMR: 0xffffffffffffffff
New AMR value (PID 34912): 0x0fffffffffffffff
I mean this line:
AMR after fork (PID 34914): 0x0000000000000003
Shouldn't it be the same as in the parent process?
Fixed it. Please try this patch. If it all works to your satisfaction, I
will clean it up further and send to Michael Ellermen(ppc maintainer).
commit 51f4208ed5baeab1edb9b0f8b68d7144449b3527
Author: Ram Pai <linuxram@xxxxxxxxxx>
Date: Sun Jun 3 14:44:32 2018 -0500
Fix for the fork bug.
Signed-off-by: Ram Pai <linuxram@xxxxxxxxxx>
Is this on top of the previous patch, or a separate fix?
top of previous patch.
Thanks. With this patch, I get this on an LPAR:
AMR (PID 1876): 0x0000000000000003
AMR after fork (PID 1877): 0x0000000000000003
AMR (PID 1877): 0x0000000000000003
Allocated key in subprocess (PID 1877): 2
Allocated key (PID 1876): 2
Setting AMR: 0xffffffffffffffff
New AMR value (PID 1876): 0x0fffffffffffffff
About to call execl (PID 1876) ...
AMR (PID 1876): 0x0000000000000003
AMR after fork (PID 1878): 0x0000000000000003
AMR (PID 1878): 0x0000000000000003
Allocated key in subprocess (PID 1878): 2
Allocated key (PID 1876): 2
Setting AMR: 0xffffffffffffffff
New AMR value (PID 1876): 0x0fffffffffffffff
Test program is still this one:
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-May/173198.html>
So the process starts out with a different AMR value for some
reason. That could be a pre-existing bug that was just hidden by the
reset-to-zero on fork, or it could be intentional. But the kernel
yes it is a bug, a patch for which is lined up for submission..
The fix is
commit eaf5b2ac002ad2f5bca118d7ce075ce28311aa8e
Author: Ram Pai <linuxram@xxxxxxxxxx>
Date: Mon Jun 4 10:58:44 2018 -0500
powerpc/pkeys: fix total pkeys calculation
Total number of pkeys calculation is off by 1. Fix it.
Signed-off-by: Ram Pai <linuxram@xxxxxxxxxx>
Looks good to me now. Initial AMR value is zero, as is currently intended.
So the remaining question at this point is whether the Intel behavior
(default-deny instead of default-allow) is preferable.
But if you can get the existing fixes into 4.18 and perhaps the relevant
stable kernels, that would already be a great help for my glibc work.
Thanks,
Florian
