Bug 61852

Summary: i386 pmap SMP race condition can cause lost page modification.
Product: Base System Reporter: Stephan Uphoff <ups>
Component: i386Assignee: Alan Cox <alc>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Stephan Uphoff 2004-01-24 23:40:08 UTC 
The current i386 pmap does not always atomically change ptes.
( Only clearing a pte is currently atomic)
This causes a window where setting of PG_A or PG_M of the pte
caused by page access of a second CPU can be ignored or overwritten 
and lost.

Lost PG_M bits can cause data loss. 
(Page not written to backing storage)

Fix: 

Import the pte update logic from the newest NetBSD pmap.
The NetBSD pmap also tries to avoid unnecessary TLB shootdowns.
Comment 1 Poul-Henning Kamp freebsd_committer freebsd_triage 2004-06-16 09:20:32 UTC 
Responsible Changed
From-To: freebsd-i386->alc

This sounds like Allans department
Comment 2 Alan L. Cox 2004-09-08 20:10:30 UTC 
Most of the cases have been dealt with in HEAD and RELENG_5.  The most 
recent being today:

alc         2004-09-08 18:58:29 UTC

   FreeBSD src repository

   Modified files:
     sys/amd64/amd64      pmap.c
     sys/i386/i386        pmap.c
   Log:
   Use atomic ops in pmap_clear_ptes() to prevent SMP races that could
   result in the loss of an accessed or modified bit from the pte.

   In collaboration with: tegge@

   MT5 candidate

   Revision  Changes    Path
   1.497     +7 -4      src/sys/amd64/amd64/pmap.c
   1.501     +13 -3     src/sys/i386/i386/pmap.c

There are, however, two cases remaining:

pmap_protect: No locked read-modify-write instruction to clear PG_RW.
Another CPU might perform a write to a page, setting the modified bit
after "pbits = *pte", but before "pte_store(pte, pbits)" has
completed.  The modified bit will be lost.

pmap_enter: Similar when tightening permission.
Comment 3 Alan L. Cox 2004-10-10 20:33:02 UTC 
Corrections to pmap_enter() and pmap_protect() have been committed to 
HEAD and RELENG_5.

RELENG_4 has similar problems.  No patches addressing this problem have 
been committed there.
Comment 4 Alan Cox freebsd_committer freebsd_triage 2004-10-10 21:49:21 UTC 
State Changed
From-To: open->patched

Corrective patches have been applied to HEAD and RELENG_5.  I am not 
closing this PR as a reminder that RELENG_4 has not been patched.  At 
present, I have no plans to port these patches to RELENG_4.  I leave 
that to others.
Comment 5 Gavin Atkinson 2007-05-14 18:14:03 UTC 
ups@ is planning to MFC this to RELENG_4 soon.
Comment 6 K. Macy freebsd_committer freebsd_triage 2007-11-16 22:21:04 UTC 
State Changed
From-To: patched->closed


RELENG_4 is EOL.