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. Regards, Joerg
