Messages in this thread | | | From | Kumar Gala <> | Subject | Re: return value of ptep_get_and_clear | Date | Wed, 6 Apr 2005 12:55:36 -0500 |
| |
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/
| |