On Thu, Jun 21, 2018 at 02:13:40PM +1000, Michael Ellerman wrote: > Ram Pai <linux...@us.ibm.com> writes: > > > On Tue, Jun 19, 2018 at 10:39:56PM +1000, Michael Ellerman wrote: > >> Ram Pai <linux...@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 <m...@ellerman.id.au> > >> > CC: Florian Weimer <fwei...@redhat.com> > >> > CC: Andy Lutomirski <l...@kernel.org> > >> > CC: Thiago Jung Bauermann <bauer...@linux.ibm.com> > >> > Signed-off-by: Ram Pai <linux...@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
