lkml.org 
[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86 ptep_get_and_clear question
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/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.184 / U:6.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site