In-Reply-To: <Pine.LNX.4.58.0504061006120.4635@graphe.net>
References: <Pine.LNX.4.58.0504061006120.4635@graphe.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <1a0fc11558f3bf76d1a8ab889278dcc7@freescale.com>
Content-Transfer-Encoding: 8BIT
Cc: "Nick Piggin" <nickpiggin@yahoo.com.au>,
       "LKML list" <linux-kernel@vger.kernel.org>
From: Kumar Gala <kumar.gala@freescale.com>
Subject: Re: return value of ptep_get_and_clear
Date: Wed, 6 Apr 2005 12:55:36 -0500
To: "Christoph Lameter" <christoph@lameter.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1657
Lines: 50


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/