On Mon, 07 Aug 2017 19:56:28 +1000 Michael Ellerman <m...@ellerman.id.au> wrote:
> Nicholas Piggin <npig...@gmail.com> writes: > > > On Fri, 04 Aug 2017 21:54:57 +0200 > > Andreas Schwab <sch...@linux-m68k.org> wrote: > > > >> No, this is really a 4.13-rc1 regression. > >> > >> Andreas. > >> > > > > SLB miss with MSR[RI]=0 on > > > > lbz r0,THREAD+THREAD_LOAD_FP(r7) > > > > Caused by bc4f65e4cf9d6cc43e0e9ba0b8648cf9201cd55f > > Ah of course. Not sure why I haven't seen it in any of my testing :/ > > > Hmm, I'll see if something can be done, but that MSR_RI stuff in syscall > > exit makes things fairly difficult (and will reduce performance improvement > > of this patch anyway). > > > > I'm trying to work to a point where we have a soft-RI bit for these kinds of > > uses that would avoid all this complexity. Until then it may be best to > > just revert this patch. > > OK. Let me know in the next day or two what you want to do. > > One option would be to load THREAD_LOAD_FP/THREAD_LOAD_VEC before we > turn off RI. Yeah, although that's a couple of unnecessary loads when we haven't used the fp regs. This path hits often on return from context switch, but for general syscalls it's less clear. And considering it's fairly tricky code at this point I'm thinking maybe just revert it for now? Thanks, Nick