Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE

Linus Torvalds
2004-05-25T18:05:09Z

On Tue, 25 May 2004, David S. Miller wrote:
> On Tue, 25 May 2004 10:49:21 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > So what I can tell, the fix is really something like this (this does both
> > x86 and ppc64 just to show how two different approaches would handle it,
> > but I have literally _tested_ neither).
> >
> > What do people think?
>
> So on sparc32 sun4m we'd implement ptep_update_dirty_accessed() with
> some kind of loop using the swap instruction?

Yes. Except that if everybody else uses atomic updates (including the hw
walkers), _and_ "dirty" is true, then you can optimize that case to just
to an atomic write (since we don't care what the previous contents were,
and everybody else is guaranteed to honor the fact that we set all the
bits.

(And an independent optimization is obviously to not do the store at all
if it is already has the new value, although that _should_ be the rare
case, since if that was true I don't see why you got a page fault in the
first place).

So _if_ such an atomic loop is fundamentally expensive for some reason, it
should be perfectly ok to do

if (dirty) {
one atomic write with all the bits set;
} else {
cmpxchg until successful;
}

Oh - btw - my suggested patch was totally broken for ppc64, because that
"ptep_update_dirty_accessed()" thing obviously also needs to that damn
hpte_update() crud etc.

BenH - I'm leaving that ppc64 code to somebody knows what the hell he is
doing. Ie you or Anton or something. Ok? I can act as a collector the
different architecture things for that "ptep_update_dirty_accessed()"
function.

Linus