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? cheers
