cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c

[Alan Cox]

alc         2004-09-22 05:01:48 UTC

  FreeBSD src repository

  Modified files:
    sys/amd64/amd64      pmap.c 
    sys/i386/i386        pmap.c 
  Log:
  Correct a long-standing error in _pmap_unwire_pte_hold() affecting
  multiprocessors.  Specifically, the error is conditioning the call to
  pmap_invalidate_page() on whether the pmap is active on the current CPU.
  This call must be unconditional.  Regardless of whether the pmap is active
  on the CPU performing _pmap_unwire_pte_hold(), it could be active on another
  CPU.  For example, a call to pmap_remove_all() by the page daemon could
  result in a call to _pmap_unwire_pte_hold() with the pmap inactive on the
  current CPU and active on another CPU.  In such circumstances, failing to
  call pmap_invalidate_page() results in a stale TLB entry on the other CPU
  that still maps the now deallocated page table page.  What happens next is
  typically a mysterious panic in pmap_enter() by the other CPU, either
  "pmap_enter: attempted pmap_enter on 4MB page" or "pmap_enter: pte vanished,
  va: 0x%lx".  Both occur because the former page table page has been recycled
  and allocated to a new purpose.  Consequently, it no longer contains zeroes.
  
  See also Peter's i386/i386/pmap.c revision 1.448 and the related e-mail
  thread last year.
  
  Many thanks to the engineers at Sandvine for providing clear and concise
  information until all of the pieces of the puzzle fell into place and
  for testing an earlier patch.
  
  MT5 Candidate
  
  Revision  Changes    Path
  1.502     +6 -7      src/sys/amd64/amd64/pmap.c
  1.508     +5 -10     src/sys/i386/i386/pmap.c