Re: Question about pte_offset_map_lock

[Hugh Dickins <hugh.dickins@tiscali.co.uk>]

On Thu, 17 Dec 2009, Minchan Kim wrote:
> It may be a dumb question.
> 
> As I read the code of pte_lock, I have a question. 
> Now, there is pte_offset_map_lock following as. 
> 
> #define pte_offset_map_lock(mm, pmd, address, ptlp)     \
> ({                                                      \
>         spinlock_t *__ptl = pte_lockptr(mm, pmd);       \
>         pte_t *__pte = pte_offset_map(pmd, address);    \
>         *(ptlp) = __ptl;                                \
>         spin_lock(__ptl);                               \
>         __pte;                                          \
> })
> 
> Why do we grab the lock after getting __pte?
> Is it possible that __pte might be changed before we grab the spin_lock?
> 
> Some codes in mm checks original pte by pte_same. 
> There are not-checked cases in proc. As looking over the cases,
> It seems no problem. But in future, new user of pte_offset_map_lock 
> could mistake with that?

I think you wouldn't be asking the question if we'd called it __ptep.

It's a (perhaps kmap_atomic) pointer into the page table: the virtual
address of a page table entry, not the page table entry itself.

You're right that the entry itself could change before we get the lock,
and pte_same() is what we use to check that an entry is still what we
were expecting; but the containing page table will remain the same,
until munmap() or exit_mmap() at least.

(For completeness, I ought to add that the entry might even change
while we have the lock: accessed and dirty bits could get set by a
racing thread in userspace.  There are places where we have to be
very careful about not missing a dirty bit, but missing an accessed
bit on rare occasions doesn't matter.)

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>