kernel - pmap (mainly i386) - fix TLB race and other issues
authorMatthew Dillon <dillon@apollo.backplane.com>
Wed, 30 Dec 2009 17:10:18 +0000 (09:10 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Wed, 30 Dec 2009 17:19:02 +0000 (09:19 -0800)
commit5926987a8c7f76518fb332134f1f6c2f3db89862
treefdd58a307b1d00efa528893f67cd95d4f3658880
parente193508c7255b6262b69e52689a301312ad53178
kernel - pmap (mainly i386) - fix TLB race and other issues

* Temporary fix for a TLB race.  Due to threading a process pmap
  may be mapped to multiple cpus.  The APTmap is built into the
  per-process pmap and used for temporary page table mappings.

  The i386 pmap code was only invalidating the TLB if the APTmap
  had to be updated, but did not consider the possibility that
  it would be accessed from a different cpu than the one it was
  originally installed in.

  Add a simple global cpumask to avoid the degenerate case.
  This is a bit of overkill.  A followup commit will move
  APTmap into the globaldata structure as a more permanent
  fix.

  The vkernel and x86_64 pmap code do not have this issue.  The
  vkernel pmap code already uses a per-globaldata pmap and
  the x86_64 pmap code uses the direct phys map.

* Add a ton of debugging code articulated with PMAP_DEBUG in
  case I ever have to do this again.  Default disabled.

* Fix a few minor issues in the pmap code.

  (1) The pv in pmap_remove_entry() is not optional.

  (2) Add a few minor missing pmap->pm_generation increments.

  (3) Add a missing critical section.

  (4) Remove an unused #define.

* Zalloc code.  No specific bugs but make sure the ZONE_INTERRUPT
  code acquires the MP lock when/if it needs to expand the mapping.

Reported-by: YONETANI Tomokazu <y0netan1@crater.dragonflybsd.org>
sys/platform/pc32/i386/pmap.c
sys/platform/pc32/include/pmap.h
sys/platform/pc64/x86_64/pmap.c
sys/platform/vkernel/platform/pmap.c
sys/vm/vm_zone.c