Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Sep 2004 20:54:03 -0600
From:      Scott Long <scottl@samsco.org>
To:        Alan Cox <alc@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Message-ID:  <41523ACB.8090707@samsco.org>
In-Reply-To: <200409220501.i8M51m8l009598@repoman.freebsd.org>
References:  <200409220501.i8M51m8l009598@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41523ACB.8090707>