RE: Fix race in the accessed/dirty bit handlers

From: Christoph Lameter <>
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)
        return __pte(xchg((long *) ptep, 0));
        pte_t pte = *ptep;
        pte_clear(mm, addr, ptep);
        return pte;

and from asm-generic/pgtable.h:

#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;                                                          \

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))

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
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