RE: Fix race in the accessed/dirty bit handlers

From: Christoph Lameter <clameter_at_engr.sgi.com>
Date: 2006-03-09 09:32:05
On Wed, 8 Mar 2006, Luck, Tony wrote:

> >Page migration is particular suitable for the creation of this race since
> >it needs to remove and restore page table entries.
> 
> I'm trying to understand why we haven't seen this problem before page
> migration was invented.  Surely in the swapout case we have the same
> situation ... swapper does "*pte = 0 ... ptc" to zap the pte and nuke
> the TLB (in that order), but there is a window in between where the
> process might try to update the accessed/dirty bits.
> 
> Have we just been lucky?

Yes. The window is very small. The zapping must happen between the 
generation of the accessed/dirty fault and the cmpxchg in the 
dirty/accessed bit handlers. It seems also that most HPC machines do not 
use swap making it highly unlikely to encounter this race. The other cases 
where this could occur are probably even rarer.

> Is the window much wider for the process migration case?

Process migration must unmap all ptes in order to migrate a page. The 
testcase here was a loop that continually moves a set of processes 
(aim7) in order to stress page migration and correspondingly the page 
table handling of the VM.
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Mar 09 09:32:43 2006

This archive was generated by hypermail 2.1.8 : 2006-03-09 09:32:52 EST