kernel - Fix IPI signaling issue, add a few assertions
authorMatthew Dillon <dillon@apollo.backplane.com>
Sat, 12 Nov 2011 06:31:27 +0000 (22:31 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sat, 12 Nov 2011 06:31:27 +0000 (22:31 -0800)
commitc17a6852f80ce59ea0641ae01d0b3c52f0584101
treefceffc11d96c4dcc659c39eea709fd1f54dfac9a
parent94f98873ae3f49c05cb6155508726f987a584cae
kernel - Fix IPI signaling issue, add a few assertions

* Change the low-level IPI code to physically disable interrupts when
  waiting for the ICR status bit to clear and issuing a new IPI.  It
  appears that on Intel cpus it is possible for (with circumstantial
  evidence) a LAPIC EOI to busy the command sequencer.

  Thus if interrupts are enabled inside a critical section, even if all
  they do is EOI the LAPIC and IRET, this can prevent an IPI from being
  sent if the interrupt occurs at just the right moment during an IPI
  operation.

* Because IPIs are already limited to one per target cpu at any given
  moment via gd->gd_npoll we can also do away with the ipiq polling
  code that was inside the ICR wait.

* Add a few assertions to try to catch other possible MP problems.

  Assert that TDF_TSLEEPQ is not set when freeing a thread.

  Assert that the cpusync ipiq does not overflow.

  Assert that the vm_object hold count does not go negative.

Reported-by: ftigeot
sys/kern/lwkt_ipiq.c
sys/kern/lwkt_thread.c
sys/platform/pc64/apic/lapic.c
sys/vm/vm_object.c