lkml.org 
[lkml]   [2005]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: return value of ptep_get_and_clear
Date

On Apr 6, 2005, at 12:09 PM, Christoph Lameter wrote:

> On Thu, 7 Apr 2005, Nick Piggin wrote:
>
> > Kumar Gala wrote:
> > > ptep_get_and_clear has a signature that looks something like:
> > >
> > > static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
> unsigned
> > > long addr,
> > >                                        pte_t *ptep)
> > >
> > > It appears that its suppose to return the pte_t pointed to by ptep
> > > before its modified.  Why do we bother doing this?  The caller
> seems
> > > perfectly able to dereference ptep and hold on to it.  Am I
> missing
> > > something here?
> > >
> >
> > You need to be able to *atomically* clear the pte and retrieve the
> > old value.
>
> The effect of the clearing is that the present bit is cleared which
> makes
> the CPU generate a fault if this pte is referenced.
>
> The problem with replacing pte values is that the code executing is
> racing
> with cpu mmu access to the pte (which may set bits on i386 I
> believe). So
> if you would access the pte and then clear it later then there would
> be a
> small window where the MMU could modify the pte. These changes would
> not
> be detected since you later overwrite the pte.
>
> Using ptep_get_and_clear insures that this does not happen...

Thanks, I was guessing that getting the value atomically was why this
was done after I give it a bit more thought.

- kumar

-
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-04-06 19:59    [W:0.046 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site