Messages in this thread | | | Date | Fri, 16 Feb 2001 17:23:40 +0100 | From | Manfred Spraul <> | Subject | Re: x86 ptep_get_and_clear question |
| |
Jamie Lokier wrote: > > And how does that lose a dirty bit? > > For the other processor to not write a dirty bit, it must have a dirty ^^^^^^^^^^^ > TLB entry already which, along with the locked cycle in > ptep_get_and_clear, means that `entry' will have _PAGE_DIRTY set. The > dirty bit is not lost. > The other cpu writes the dirty bit - we just overwrite it ;-) After the ptep_get_and_clear(), before the set_pte().
The current assumption about the page dirty logic is: A cpu that has a writable, non-dirty pte cached in its tlb it may unconditionally set the dirty bit - without honoring present or write protected bits.
--> set_pte() can either loose a dirty bit or a 'pte_none() entry' could suddenly become a swap entry unless it's guaranteed that no cpus has a cached valid tlb entry.
Linus, does the proposed pte gather code handle the second part? pte_none() suddenly becomes 0x0040.
Back to the current mprotect.c code:
pte is writable, not-dirty.
cpu1: has a writable, non-dirty pte in it's tlb. cpu 2: in mprotect.c entry = ptep_get_and_clear(pte); * pte now clear. * entry contains the pte value without the dirty bit cpu decodes a write instruction, and dirties the pte. lock; orl DIRTY_BIT, *pte set_pte(pte, pte_modify(entry, newprot)); * pte overwritten with entry.
--> dirty bit lost.
-- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |