RE: Fix race in the accessed/dirty bit handlers

From: Chen, Kenneth W <>
Date: 2006-03-10 06:44:51
Christoph Lameter wrote on Thursday, March 09, 2006 10:28 AM
> On Thu, 9 Mar 2006, Zoltan Menyhart wrote:
> > In short: unless we use "srlz.d", how to make sure:
> > - the visibility of the "itc" instruction to generated purges is
> >   guaranteed first
> > - issuing "ld" goes after ?

Let's go back one step, the guarantee is coming from the fact that happens after pte change.  And the fault handler guarantees
that by the time 2nd load happens, TLB state is consistent with
what is in the software page table.  It doesn't matter where the come through.  As long as the TLB state is consistent with
respect to software page table, we are fine.  Considering the
following 3 cases:

CPU A        CPU B       | CPU A       CPU B     | cpu A    cpu B
-----        -----       | -----       -----     | -----    -----
             change pte  |                       |
                         |                       |
read pte                 |read pte               |read pte
insert TLB               |           change pte  |insert
re-read                  |insert                 |re-read
                         |re-read                |          change pte

Global purge doesn't need to come into the picture here.

> I guess this scheme could fail if the remote processor would 
> zap the pte and do the broadcast between the local processors cmpxchg
> and the itc. Thats only two bundles. 

How can that fail?:

cpu A         cpu B
-----         -----

- Ken

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Fri Mar 10 06:46:01 2006

This archive was generated by hypermail 2.1.8 : 2006-03-10 06:46:12 EST