On Tue, Jul 17, 2018 at 12:15 AM, Joerg Roedel <jroedel@xxxxxxx> wrote: > On Sat, Jul 14, 2018 at 07:36:47AM -0700, Andy Lutomirski wrote: >> 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. > > The code switches to the kernel-stack and kernel-cr3 and just remembers > where it came from (to handle the entry-from-kernel with entry-stack > and/or user-cr3 case). IRQs are disabled in the entry-code path. But > ultimately it calls into C code to handle the exception. And there IRQs > might get enabled again. > >> 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. > > Right, IRET is handled differently and doesn't need this patch. But the > segment-writing exceptions do. > > If you insist on it I can try to implement the assumption that we don't > get preempted in this code-path. That will safe us some cycles for > copying stack contents in this unlikely slow-path. But we definitly need > to handle the entry-from-kernel with entry-stack and/or user-cr3 case > correctly and make a switch to kernel-stack/cr3 because we are going to > call into C-code. > > Yes, we obviously need to restore the correct cr3. But I really don't like the code that rewrites the stack frame that we're about to IRET to, especially when it doesn't seem to serve a purpose. I'd much rather the code just get its CR3 right and do the IRET and trust that the frame it's returning to is still there.
