From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 16 Mar 2001 12:53:38 +0000 From: "Stephen C. Tweedie" Subject: Re: changing mm->mmap_sem (was: Re: system call for process information?) Message-ID: <20010316125338.L30889@redhat.com> References: <20010316094918.F30889@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from riel@conectiva.com.br on Fri, Mar 16, 2001 at 08:50:25AM -0300 Sender: owner-linux-mm@kvack.org Return-Path: To: Rik van Riel Cc: "Stephen C. Tweedie" , george anzinger , Alexander Viro , linux-mm@kvack.org, bcrl@redhat.com, linux-kernel@vger.kernel.org List-ID: Hi, On Fri, Mar 16, 2001 at 08:50:25AM -0300, Rik van Riel wrote: > On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > > > > Write locks would be used in the code where we actually want > > > to change the VMA list and page faults would use an extra lock > > > to protect against each other (possibly a per-pagetable lock > > > > Why do we need another lock? The critical section where we do the > > final update on the pte _already_ takes the page table spinlock to > > avoid races against the swapper. > > The problem is that mmap_sem seems to be protecting the list > of VMAs, so taking _only_ the page_table_lock could let a VMA > change under us while a page fault is underway ... Right, I'm not suggesting removing that: making the mmap_sem read/write is fine, but yes, we still need that semaphore. But as for the "page faults would use an extra lock to protect against each other" bit --- we already have another lock, the page table lock, which can be used in this way, so ANOTHER lock should be unnecessary. --Stephen -- 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.eu.org/Linux-MM/