Timur Tabi <timur.tabi@ammasso.com> writes: > Ed L Cashin wrote: > >> The normal order of lock acquisition is first to get the mmap >> semaphore (at which point you may sleep) and then to get the page >> table lock. > > So you're saying I need to use > > down_read(¤t->mm->mmap_sem); lock spinlock access page tables unlock spinlock > up_read(¤t->mm->mmap_sem); > > In addition to the spinlocks? Yes, nested as above. >> A good reference for the proceedure you're implementing is follow_page >> in mm/memory.c. Note that it's called with the page_table_lock held. > > I'm looking at follow_page() in 2.6.6, and I don't see any spinlock or > semaphore code. The code in RedHat 9.0 is also similar in this > respect. You should see a comment at the top that says the caller needs to have the page table lock. That implies that the caller already has the mmap semaphore. I was hoping to recommend Documentation/vm/locking as a reference, but at a quick glance it doesn't seem so clear on the point we're discussing. Check the callers of follow_page, and you should see them getting the mmap semaphore before taking the page table lock and then finally calling follow_page. Folks hold onto the mmap semaphore for longer periods of time, so you might have to search up the call chain a ways. >> No, the page table lock allows you to see a consistent view of the >> page tables while you hold it. > > Is "¤t->mm->page_table_lock" the right parameter to use in this case? Yes, to access the current process' page tables, assuming you're in process context. -- Ed L Cashin <ecashin@coraid.com> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
