kernel - Fix MP race in kmalloc/kfree
commitdf9daea899a8461728f182d303b51686d5e6a3dc
authorMatthew Dillon <dillon@apollo.backplane.com>
Thu, 30 Sep 2010 00:01:53 +0000 (29 17:01 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Thu, 30 Sep 2010 00:01:53 +0000 (29 17:01 -0700)
tree82bad9c4d11a5d37ab83970bf2e119f8fdeedd0d
parentebc5d930cf100d61351cfe5f9cbb168613294835
kernel - Fix MP race in kmalloc/kfree

* Fix two cases where a zone is mis-handled by the new kfree().  Note,
  however, that the race being fixed is nearly impossible (might even
  BE impossible) to produce because it requires a slab to go from
  completely empty to completely full through hysteresis and then destroyed
  all in a few microseconds.

  Essentially when a kfree() occurs on a cpu which is not the owner of
  the zone the chunk is linked into a side-list on the zone using atomic
  ops.  Under certain (very rare) circumstances the cpu doing the kfree()
  must IPI the cpu that owns the zone.

  The moment the chunk is linked in the cpu owning the zone can race the
  incoming IPI and destroy the zone (if it is now completely unused).
  The old kmemusage code handled the race just fine but the new vm_page_t
  based big-block handler could not.

  The solution is to have an atomic-ops counter for inflight IPIs which
  prevents the owning cpu from destroying the zone prematurely.
sys/kern/kern_slaballoc.c
sys/sys/slaballoc.h