[lkml]   [2018]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 10/39] x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack
On Tue, Jul 17, 2018 at 12:15 AM, Joerg Roedel <> 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.

 \ /
  Last update: 2018-07-17 22:06    [W:0.143 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site