On Wed, Jan 23, 2019 at 06:40:08PM +0000, James Morse wrote:
> My SMM comment was because the CPU must jump from user-space->SMM, which injects
> an NMI into the kernel. The kernel's EIP must point into user-space, so
> returning from the NMI without doing the memory_failure() work puts us back the
> same position we started in.
Yeah, known issue. We dealt with that on x86 at the time:
d4812e169de4 ("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks")
> > Now, memory_failure_queue() does that and can run from IRQ context so
> > you need only an irq_work which can queue from NMI context. We do it
> > this way in the MCA code:
> >
>
> (was there something missing here?)
Whoops. Yeah, I was about to paste this:
void mce_log(struct mce *m)
{
if (!mce_gen_pool_add(m))
irq_work_queue(&mce_irq_work);
}
we're basically queueing only into the lockless buffer and kicking the
IRQ work.
> > We queue in an irq_work in NMI context and work through the items in
> > process context.
>
> How are you getting from NMI to process context in one go?
Well, #MC is basically an NMI context on x86 and when it is done, we
work through the items queued in process context. But see the commit
above too - for really urgent errors we run memory_failure *before* we
return to user.
> This patch causes the IRQ->process transition.
> The arch specific bit of this gives the irq work queue a kick if returning from
> the NMI would unmask IRQs. This makes it look like we moved from NMI to IRQ
> context without returning to user-space.
>
> Once ghes_handle_memory_failure() runs in IRQ context, it task_work_add()s the
> call to ghes_kick_memory_failure().
>
> Finally on the way out of the kernel to user-space that task_work runs and the
> memory_failure() work happens in process context.
>
> During all this the user-space program counter can point at a poisoned location,
> but we don't return there until the memory_failure() work has been done.
Sounds very similar.
Actually, yours is even a bit more elegant. I wonder why we didn't use
task_work_add() then...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
