Re: changing mm->mmap_sem (was: Re: system call for process information?)

2001-03-19 Thread Stephen C. Tweedie
Hi, On Sun, Mar 18, 2001 at 10:34:38AM +0100, Manfred Spraul wrote: > > 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 ... > > No, that can't happen. It can. Page

Re: changing mm->mmap_sem (was: Re: system call for process information?)

2001-03-18 Thread Manfred Spraul
> > 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 ... No, that can't happen. VMA changes only happen if both the mmap_sem and the page table lock is acquired. (check ins

Re: changing mm->mmap_sem (was: Re: system call for process information?)

2001-03-16 Thread Stephen C. Tweedie
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 (possib

Re: changing mm->mmap_sem (was: Re: system call for process information?)

2001-03-16 Thread Stephen C. Tweedie
Hi, On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote: > On Wed, 14 Mar 2001, Rik van Riel wrote: > The mmap_sem is used in procfs to prevent the list of VMAs > from changing. In the page fault code it seems to be used > to prevent other page faults to happen at the same time with > t

changing mm->mmap_sem (was: Re: system call for process information?)

2001-03-15 Thread Rik van Riel
On Wed, 14 Mar 2001, Rik van Riel wrote: > On Wed, 14 Mar 2001, george anzinger wrote: > > > Is it REALLY necessary to prevent them from seeing an > > inconsistent state? Seems to me that in the total picture (i.e. > > system wide) they will never see a consistent state, so why be > > concerned