On Sat, Jul 25, 2015 at 10:56 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> >> And people will give me five new heads if I ignore Linus and do RET >> even with IF=1, saving 300 cycles? > > So I'm still nervous about that "sti; ret" when we're back on the > original kernel stack that took the original fault or interrupt. But > it's probably ok. > > Yes, it's irq-safe. But it's not NMI-safe, so if an NMI happens there, > when the NMI returns, an interrupt might occur there too. But since > we're back on the original stack where the original fault happened, > and since interrupts were enabled, I don't see why that would be > horrible. In theory, we might have a growing stack if this keeps > happening, but since the only way to get that is to get the NMI in > that one-instruction window (and apparently on at least _some_ > microarchitectures the sti shadow stops even NMI's), I don't see how > any kind of unbounded growth would happen. > > So. > > I think it would work, and it might even be good for "coverage" (ie > the whole "iret-to-ret-conversion" will not have a lot of testing if > it only happens for faults with interrupts disabled). > > But it still worries me a bit. >
What if we added something like: if (regs->ip == ret_after_sti && !user_mode(regs) && (regs->flags & X86_EFLAGS_IF)) { regs->ip--; regs->flags &= ~X86_EFLAGS_IF; } to do_nmi, do_machine_check, and do_debug (the latter because kernel breakpoints, damnit)? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/