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> diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c index 4530cdf..3384c4e 100644 --- a/arch/powerpc/mm/pkeys.c +++ b/arch/powerpc/mm/pkeys.c @@ -93,7 +93,7 @@ int pkey_initialize(void) * arch-neutral code. */ pkeys_total = min_t(int, pkeys_total, - (ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)); + ((ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)+1)); if (!pkey_mmu_enabled() || radix_enabled() || !pkeys_total) static_branch_enable(&pkey_disabled);
