Re: [PATCH 10/39] x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack

[Andy Lutomirski]

> 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