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. RP
