int3 uses IST and the paranoid gsbase path. Neither is necessary, although the IST stack may currently be necessary to avoid stack overruns.
Clean up IRQ stacks, make them NMI safe, teach idtentry to use irqstacks if requested, and move int3 to the IRQ stack. This prepares us to return from int3 using RET. While we could, in principle, return from an IST entry using RET, making that work seems likely to be much messier and more fragile than this approach. Andy Lutomirski (3): x86/entry/64: Refactor IRQ stacks and make then NMI-safe x86/entry/64: Teach idtentry to use the IRQ stack x86/entry/64: Move #BP from IST to the IRQ stack arch/x86/entry/entry_64.S | 88 ++++++++++++++++++++++++++++---------------- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/process_64.c | 4 ++ arch/x86/kernel/traps.c | 26 ++++++------- 4 files changed, 74 insertions(+), 46 deletions(-) -- 2.4.3 -- 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/
