On Wed, Sep 28, 2016 at 3:44 PM, Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote: > On 09/28/2016 03:26 PM, Andy Lutomirski wrote: >>>>>> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode >>>>>> > > >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want >>>>>> > > >> the very late register restore parts to be non-interruptible, but is this required >>>>>> > > >> before we call prrempt_schedule_irq() off of asm code. >>>>> > > > >>>>> > > > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who >>>>> > > > might actually know this off the top of his head. I'll try and dig >>>>> > > > through x86 to see what it does. >>>> > > >>>> > > On x86, it's quite simple. IRQs are *always* off during the final >>>> > > register restore, and we don't re-check for preemption there. x86 >>>> > > handles preemption after turning off IRQs, and IRQs are guaranteed to >>>> > > stay off until we actually return to userspace. >>>> > > >>>> > > The code is almost entirely in C in arch/x86/entry/common.c. There >>>> > > isn't anything particularly x86-speficic in there. >>> > >>> > Right, so what I think Vineet is asking is if we need to disable NMIs as >>> > well, we cannot on x86 disable NMIs so no. >>> > >> The same argument works here, too: an NMI won't set TIF_NEED_RESCHED >> without sending an IPI, so we can't miss a wakeup. > > The case I saw was different: timer intr (normal prio) comes in - scheduler_tick() > sets TIF_NEED_RESCHED and before this intr return, it gets interrupted by perf > intr (higher prio) and we decide not to follow through on preemption because a > nested intr can't return to userspace anyways. > > This shouldn't cause a problem. When the timer interrupt returns, it should be able to handle preemption.
