lkml.org 
[lkml]   [2001]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: x86 ptep_get_and_clear question
    Kanoj Sarcar wrote:
    > > Here's the important part: when processor 2 wants to set the pte's dirty
    > > bit, it *rereads* the pte and *rechecks* the permission bits again.
    > > Even though it has a non-dirty TLB entry for that pte.
    > >
    > > That is how I read Ben LaHaise's description, and his test program tests
    > > exactly this.
    >
    > Okay, I will quote from Intel Architecture Software Developer's Manual
    > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27:
    >
    > "Bus cycles to the page directory and page tables in memory are performed
    > only when the TLBs do not contain the translation information for a
    > requested page."
    >
    > And on the same page:
    >
    > "Whenever a page directory or page table entry is changed (including when
    > the present flag is set to zero), the operating system must immediately
    > invalidate the corresponding entry in the TLB so that it can be updated
    > the next time the entry is referenced."
    >
    > So, it looks highly unlikely to me that the basic assumption about how
    > x86 works wrt tlb/ptes in the ptep_get_and_clear() solution is correct.

    To me those quotes don't address the question we're asking. We know
    that bus cycles _do_ occur when a TLB entry is switched from clean to
    dirty, and furthermore they are locked cycles. (Don't ask me how I know
    this though).

    Does that mean, in jargon, the TLB does not "contain
    the translation information" for a write?

    The second quote: sure, if we want the TLB updated we have to flush it.
    And eventually in mm/mprotect.c we do. But what before, it keeps on
    using the old TLB entry? That's ok. If the entry was already dirty
    then we don't mind if processor 2 continues with the old TLB entry for a
    while, until we do the big TLB range flush.

    In other words I don't think those two quotes address our question at
    all.

    What worries more is that this is quite a subtle requirement, and the
    code in mm/mprotect.c is not specific to one architecture. Do all SMP
    CPUs support by Linux do the same thing on converting TLB entries from
    clean to dirty, or do they have a subtle, easily missed data integrity
    problem?

    -- Jamie
    -
    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:17    [W:0.037 / U:0.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site