> On Jul 14, 2018, at 1:01 AM, Joerg Roedel <jroedel@xxxxxxx> wrote: > > On Fri, Jul 13, 2018 at 11:26:54PM -0700, Andy Lutomirski wrote: >>> So based on that, I did the above because the entry-stack is a per-cpu >>> data structure and I am not sure that we always return from the exception >>> on the same CPU where we got it. Therefore the path is called >>> PARANOID_... :) >> >> But we should just be able to IRET and end up right back on the entry >> stack where we were when we got interrupted. > > Yeah, but using another CPUs entry-stack is a bad idea, no? Especially > since the owning CPU might have overwritten our content there already. > >> On x86_64, we *definitely* can’t schedule in NMI, MCE, or #DB because >> we’re on a percpu stack. Are you *sure* we need this patch? > > I am sure we need this patch, but not 100% sure that we really can > change CPUs in this path. We are not only talking about NMI, #MC and > #DB, but also about #GP and every other exception that can happen while > writing segments registers or on iret. With this implementation we are > on the safe side for this unlikely slow-path. Oh, right, exceptions while writing segment regs. IRET is special, though. But I’m still unconvinced. If any code executed with IRQs enabled on the entry stack, then that code is terminally buggy. If you’re executing with IRQs off, you’re not going to get migrated. 64-bit kernels run on percpu stacks all the time, and it’s not a problem. IRET errors are genuinely special and, if they’re causing a problem for you, we should fix them the same way we deal with them on x86_64. M > > Regards, > > Joerg
