]> CyberLeo.Net >> Repos - FreeBSD/releng/10.2.git/commit
MFC: r285839 (r286055 in stable/10)
authormarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 30 Jul 2015 02:45:35 +0000 (02:45 +0000)
committermarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 30 Jul 2015 02:45:35 +0000 (02:45 +0000)
commita9c5032ad36618ad8a1a25d27fb548b29e655493
tree0e59edc211623442700129ad9694c3be7ce0658a
parent18fd9598007558af62d8e9f4f7f7ef8557d4f9bf
MFC: r285839 (r286055 in stable/10)

o Revert the other functional half of r239864, i. e. the merge of r134227
  from x86 to use smp_ipi_mtx spin lock not only for smp_rendezvous_cpus()
  but also for the MD cache invalidation, TLB demapping and remote register
  reading IPIs due to the following reasons:
  - The cross-IPI SMP deadlock x86 otherwise is subject to can't happen on
    sparc64. That's because on sparc64, spin locks don't disable interrupts
    completely but only raise the processor interrupt level to PIL_TICK. This
    means that IPIs still get delivered and direct dispatch IPIs such as the
    cache invalidation etc. IPIs in question are still executed.
  - In smp_rendezvous_cpus(), smp_ipi_mtx is held not only while sending an
    IPI_RENDEZVOUS, but until all CPUs have processed smp_rendezvous_action().
    Consequently, smp_ipi_mtx may be locked for an extended amount of time as
    queued IPIs (as opposed to the direct ones) such as IPI_RENDEZVOUS are
    scheduled via a soft interrupt. Moreover, given that this soft interrupt
    is only delivered at PIL_RENDEZVOUS, processing of smp_rendezvous_action()
    on a target may be interrupted by f. e. a tick interrupt at PIL_TICK, in
    turn leading to the target in question trying to send an IPI by itself
    while IPI_RENDEZVOUS isn't fully handled, yet, and, thus, resulting in a
    deadlock.
o As mentioned in the commit message of r245850, on least some sun4u platforms
  concurrent sending of IPIs by different CPUs is fatal. Therefore, hold the
  reintroduced MD ipi_mtx also while delivering cross-traps via MI helpers,
  i. e. ipi_{all_but_self,cpu,selected}().
o Akin to x86, let the last CPU to process cpu_mp_bootstrap() set smp_started
  instead of the BSP in cpu_mp_unleash(). This ensures that all APs actually
  are started, when smp_started is no longer 0.
o In all MD and MI IPI helpers, check for smp_started == 1 rather than for
  smp_cpus > 1 or nothing at all. This avoids races during boot causing IPIs
  trying to be delivered to APs that in fact aren't up and running, yet.
  While at it, move setting of the cpu_ipi_{selected,single}() pointers to
  the appropriate delivery functions from mp_init() to cpu_mp_start() where
  it's better suited and allows to get rid of the global isjbus variable.
o Given that now concurrent IPI delivery no longer is possible, also nuke
  the delays before completely disabling interrupts again in the CPU-specific
  cross-trap delivery functions, previously giving other CPUs a window for
  sending IPIs on their part. Actually, we now should be able to entirely get
  rid of completely disabling interrupts in these functions. Such a change
  needs more testing, though.
o In {s,}tick_get_timecount_mp(), make the {s,}tick variable static. While not
  necessary for correctness, this avoids page faults when accessing the stack
  of a foreign CPU as {s,}tick now is locked into the TLBs as part of static
  kernel data. Hence, {s,}tick_get_timecount_mp() always execute as fast as
  possible, avoiding jitter.

PR: 201245
Approved by: re (gjb)

git-svn-id: https://svn.freebsd.org/base/releng/10.2@286060 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/kern/subr_witness.c
sys/sparc64/include/smp.h
sys/sparc64/sparc64/machdep.c
sys/sparc64/sparc64/mp_machdep.c
sys/sparc64/sparc64/tick.c