On Apr 28, 2019, at 2:22 PM, Nicolai Stange nstange@suse.de wrote:
Steven Rostedt rostedt@goodmis.org writes:
On Sun, 28 Apr 2019 10:41:10 -0700 Andy Lutomirski luto@amacapital.net wrote:
Note that at any given point in time, there can be at most four such call insn emulations pending: namely at most one per "process", "irq", "softirq" and "nmi" context.
That’s quite an assumption. I think your list should also contain exception, exceptions nested inside that exception, and machine check, at the very least. I’m also wondering why irq and softirq are treated separately.
You're right, I missed the machine check case.
4 has usually been the context count we choose. But I guess in theory, if we get exceptions then I could potentially be more.
After having seen the static_call discussion, I'm in no way defending this limited approach here, but out of curiosity: can the code between the push onto the stack from ftrace_int3_handler() and the subsequent pop from the stub actually trigger an (non-#MC) exception? There's an iret inbetween, but that can fault only when returning to user space, correct?
IRET doesn’t do any fancy masking, so #DB, NMI and regular IRQs should all be possible.
As for irq vs softirq, an interrupt can preempt a softirq. Interrupts are enabled while softirqs are running. When sofirqs run, softirqs are disabled to prevent nested softirqs. But interrupts are enabled again, and another interrupt may come in while a softirq is executing.
Thanks,
Nicolai
-- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)