Re: x86 ptep_get_and_clear question

Jamie Lokier (lk@tantalophile.demon.co.uk)
Fri, 16 Feb 2001 17:00:29 +0100


Manfred Spraul wrote:
> > entry = ptep_get_and_clear(pte);
> > set_pte(pte, pte_modify(entry, newprot));
> >
> > I.e. the only code with the race condition is code which explicitly
> > clears the dirty bit, in vmscan.c.
> >
> > Do you see any possibility of losing a dirty bit here?
> >
> Of course.
> Just check the output after preprocessing.
> It's
> int entry;
> entry = *pte;
> entry &= ~_PAGE_CHG_MASK;
> entry |= pgprot_val(newprot)
> *pte = entry;

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.

> We need
> atomic_clear_mask (_PAGE_CHG_MASK, pte);
> atomic_set_mask (pgprot_val(newprot), *pte);
>
> for multi threaded apps.

cmpxchg is probably faster.

-- 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/