[PATCH v2 2/6] powerpc/pkeys: Save the pkey registers before fork

Ram Pai linuxram at us.ibm.com
Fri Jun 22 03:35:48 AEST 2018


On Thu, Jun 21, 2018 at 02:13:40PM +1000, Michael Ellerman wrote:
> Ram Pai <linuxram at us.ibm.com> writes:
> 
> > On Tue, Jun 19, 2018 at 10:39:56PM +1000, Michael Ellerman wrote:
> >> Ram Pai <linuxram at us.ibm.com> writes:
> >> 
> >> > When a thread forks the contents of AMR, IAMR, UAMOR registers in the
> >> > newly forked thread are not inherited.
> >> >
> >> > Save the registers before forking, for content of those
> >> > registers to be automatically copied into the new thread.
> >> >
> >> > CC: Michael Ellerman <mpe at ellerman.id.au>
> >> > CC: Florian Weimer <fweimer at redhat.com>
> >> > CC: Andy Lutomirski <luto at kernel.org>
> >> > CC: Thiago Jung Bauermann <bauerman at linux.ibm.com>
> >> > Signed-off-by: Ram Pai <linuxram at us.ibm.com>
> >> 
> >> Again this is an ABI change but we'll call it a bug fix I guess.
> >
> > yes. the same defense here too. its a behaviorial change for the better.
> > Single threaded applications will not see any behaviorial change.
> > Multithreaded apps, which were unable to consume, the behavior will now be
> > able to do so.
> 
> Well threads is one thing, but this also affects processes.
> 
> And actually without this fix it's possible that a child process could
> fault on a region protected in the parent, if the value in the AMR in
> the thread struct happens to block access at the time of fork(). The
> value in the thread struct would be whatever was in the AMR the last
> time the parent was scheduled in. I think?

right. Child processes will see stale value of AMR. Technically this
behavior is a bug, since existing applications; if any,  cannot rely on
this stale AMR value.

RP



More information about the Linuxppc-dev mailing list