RE: Fix race in the accessed/dirty bit handlers

From: Christoph Lameter <clameter_at_engr.sgi.com>
Date: 2006-03-09 09:04:25
On Wed, 8 Mar 2006, Chen, Kenneth W wrote:

> What happens to a scenario where you zap the pte right after dirty bit
> handler just finished.  Won't you lost that "dirty" information?

Well zapping is not really what happens. We do an atomic exchange with 
zero. The  dirty bit information is moved to the page_struct (and then
finally the page has a chance to be updated on disk!).
 
See in asm-ia64/pgtable.h

static inline pte_t
ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
#ifdef CONFIG_SMP
        return __pte(xchg((long *) ptep, 0));
#else
        pte_t pte = *ptep;
        pte_clear(mm, addr, ptep);
        return pte;
#endif
}


and from asm-generic/pgtable.h:

#ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH
#define ptep_clear_flush(__vma, __address, __ptep)                      \
({                                                                      \
        pte_t __pte;                                                    \
        __pte = ptep_get_and_clear((__vma)->vm_mm, __address, __ptep);  \
        flush_tlb_page(__vma, __address);                               \
        __pte;                                                          \
})
#endif


then in mm/rmap.c

/*
 * Subfunctions of try_to_unmap: try_to_unmap_one called
 * repeatedly from either try_to_unmap_anon or try_to_unmap_file.
 */
static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
                                int ignore_refs)

....


       /* Nuke the page table entry. */
        flush_cache_page(vma, address, page_to_pfn(page));
        pteval = ptep_clear_flush(vma, address, pte);

        /* Move the dirty bit to the physical page now the pte is gone. */
        if (pte_dirty(pteval))
                set_page_dirty(page);


-
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:05:03 2006

This archive was generated by hypermail 2.1.8 : 2006-03-09 09:05:15 EST