RE: Fix race in the accessed/dirty bit handlers

From: Luck, Tony <>
Date: 2006-03-11 04:28:25
> Please consider the second issue I mentioned about the "itc":
> Making sure that an external purge request will not be missed by our new
> translation. See also on page 3:127:

While this is true, I'm still not seeing how this can cause
a problem (but I didn't see the problem that Christoph just
found that started this whole thread in six years of looking
at this code, so I'm willing to accept that I may be missing

If another processor has a purge floating out there on the
bus at this time, it would be because that other processor
was making some change to this mapping.  In which case it
would have executed:

 *pte = new_value

Are you saying that these events may become visible to the
processor that is executing the dirty_bit handler in either
order, so that you are worried we'll see the old *pte value
when we do the load, but miss the purge because we didn't
wait for the itc.d to complete before we did the load?

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Sat Mar 11 04:29:37 2006

This archive was generated by hypermail 2.1.8 : 2006-03-11 04:29:46 EST