lkml.org 
[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:3.436 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site