kmdb tortures via single-step miscellaneous trap
KMDB often gets "stuck" after a :c with:
> :c kmdb: single-step stop on miscellaneous trap kmdb: target stopped at: xc_serv+0x109: movl 0x654(%r13),%eax
What appears to be happening here is (for example).
1. We set a breakpoint on a frequently-triggered breakpoint, such as hat_switch().
2. One CPU hits it, and comes through kdi_cmnint to kaif_main_loop(), and is assigned to be master.
3. Simultaneously, another CPU hits the breakpoint, and takes the same path. However, the master is already assigned, so this CPU ends up in kaif_slave_loop(). Note that interrupts are disabled. Also note, since we're now a slave, we've effectively lost the breakpoint event, and we won't ever see it in KMDB.
4. The master now calls kmdb_kdi_stop_slaves(..., 1). This cross-calls to all slave CPUs, including the one above. But interrupts are disabled while in the slave loop.
5. We choose to continue in KMDB, and resume all our CPUs back into the kernel.
6. At some point, our previous slave enables interrupts, and immediately takes the kdi_slave_entry cross-call.
7. It reaches kaif_main_loop(), becomes the new master, and drops into the prompt.
At this point, KMDB is confused, since we appeared as if from nowhere.
If we modify kdi_slave_entry to mark the CPU as a slave, and kaif_main_loop() to ignore spurious entries like this, we are good.
While we're here, we'll also:
1. add a kdiregs_t struct to make reading of ->krs_gregs much easier.
2. Fix kdi_slave_entry for better crumb entries, and also make sure KDIREG_SAVPC isn't the old value of %ss after we do the switcheroo described there.
Updated by Electric Monk over 1 year ago
- % Done changed from 0 to 100
- Status changed from New to Closed
commit 66a2141c21574ea874644d1b0703e2f175e8e8a1 Author: John Levon <firstname.lastname@example.org> Date: 2018-08-17T20:41:01.000Z 9736 kmdb tortures via single-step miscellaneous trap Reviewed by: Robert Mustacchi <email@example.com> Reviewed by: Jerry Jelinek <firstname.lastname@example.org> Reviewed by: Toomas Soome <email@example.com> Reviewed by: Andy Fiddaman <firstname.lastname@example.org> Approved by: Gordon Ross <email@example.com>