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

[Scott Long]

Alan Cox wrote:
> 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

And thanks for your help too on this!  Can I assume that this will be
merged to RELENG_5?

Scott