Hi all- On x86_64, we use IST for #BP and #DB. On x86_32, we don't.
We started using IST for #BP in: b556b35e98ad [PATCH] x86_64: Move int 3 handler to debug stack and allow to increase it. and we started using IST for #DB even earlier in: 7abe2c67299e [PATCH] x86-64 merge for 2.6.4 This has some unpleasant side effects these days. Primarily, it requires a bunch of ugly code to avoid recursive use of the debug stack when, say, an NMI interrupts do_int3 or do_debug and either hits a kprobe int3 or a #DB if it inadvertently touches a userspace watchpoint. See TRACE_IRQS_OFF_DEBUG for another bit wart in that code. Here are all of the reasons I can come up with for using IST: 1. SYSENTER with TF set will immediately (or after one instruction -- I'm not quite sure) cause #DB. This is easy to handle -- we can just set up a sysenter stack just like x86_32. 2. #DB needs paranoid gsbase handling (due to SYSENTER if nothing else). However, there's no real reason that IST and paranoid gsbase handling need to be tied together. 3. Stack usage. Almost anything can hit a kprobe and any uaccess operation can hit a watchpoint. I'm not sure how much of a problem this is. If it is a real problem, we could use something more like the irqstack mechanism instead of IST. 4. kgdb. kgdb doesn't appear to respect the kprobe blacklist at all, so kdbg would blow up if it tried to breakpoint early or late in syscall handling. (Hmm. I bet kdbg also blows up if you use it to put a breakpoint early in do_int3.) Thoughts? Even if it turns out that we can't get rid of IST for #DB and #BP, I bet we could simplify matters by rigging up the all of the IST entries to switch IST off for #DB and #BP immediately upon entry and to leave them off until immediately before returning, thereby simplifying the logic quite a bit. I think this would be a pure performance win -- the only patch here in which performance matters is NMI AFAICT, and the NMI code already does that, albeit rather deeply buried. --Andy --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/