Project

General

Profile

Bug #9736

kmdb tortures via single-step miscellaneous trap

Added by John Levon about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2018-08-15
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

SmartOS OS-5852

KMDB often gets "stuck" after a :c with:

[51]> :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.

History

#1

Updated by Electric Monk about 1 year ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 66a2141c21574ea874644d1b0703e2f175e8e8a1

commit  66a2141c21574ea874644d1b0703e2f175e8e8a1
Author: John Levon <john.levon@joyent.com>
Date:   2018-08-17T20:41:01.000Z

    9736 kmdb tortures via single-step miscellaneous trap
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Andy Fiddaman <omnios@citrus-it.net>
    Approved by: Gordon Ross <gwr@nexenta.com>

Also available in: Atom PDF