public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: george anzinger <george@mvista.com>,
	Alexander Viro <viro@math.psu.edu>,
	linux-mm@kvack.org, bcrl@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: changing mm->mmap_sem  (was: Re: system call for process information?)
Date: Fri, 16 Mar 2001 09:49:18 +0000	[thread overview]
Message-ID: <20010316094918.F30889@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0103141618320.21132-100000@duckman.distro.conectiva> <Pine.LNX.4.21.0103150919260.4165-100000@imladris.rielhome.conectiva>
In-Reply-To: <Pine.LNX.4.21.0103150919260.4165-100000@imladris.rielhome.conectiva>; from riel@conectiva.com.br on Thu, Mar 15, 2001 at 09:24:59AM -0300

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
> the current page fault (and to prevent VMAs from changing
> while a page fault is underway).

The page table spinlock should be quite sufficient to let us avoid
races in the page fault code.  We've had to deal with this before
there was ever a mmap_sem anyway: in ancient times, every page fault
had to do things like check to see if the pte had changed after IO was
complete and once the BKL had been retaken.  We can do the same with
the page fault spinlock without much pain.

> Maybe we should change the mmap_sem into a R/W semaphore ?

Definitely.

> 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.

Cheers,
 Stephen

  reply	other threads:[~2001-03-16  9:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-12 17:08 system call for process information? Guennadi Liakhovetski
2001-03-12 18:27 ` Alexander Viro
2001-03-12 21:21   ` Guennadi Liakhovetski
2001-03-13  2:56     ` Nathan Paul Simons
2001-03-13  3:20       ` Alexander Viro
2001-03-13  9:55         ` Guennadi Liakhovetski
2001-03-13 21:05       ` Albert D. Cahalan
2001-03-13 22:02         ` Nathan Paul Simons
2001-03-13 22:50           ` Albert D. Cahalan
2001-03-13 22:52         ` Rik van Riel
2001-03-14  1:53           ` Martin Dalecki
2001-03-14  2:28             ` Rik van Riel
2001-03-14  8:24               ` george anzinger
2001-03-14 19:19                 ` Rik van Riel
2001-03-14 16:27                   ` george anzinger
2001-03-15 12:24                   ` changing mm->mmap_sem (was: Re: system call for process information?) Rik van Riel
2001-03-16  9:49                     ` Stephen C. Tweedie [this message]
2001-03-16 11:50                       ` Rik van Riel
2001-03-16 12:53                         ` Stephen C. Tweedie
2001-03-18  7:23                           ` Rik van Riel
2001-03-18  9:56                             ` Mike Galbraith
2001-03-18 10:46                               ` Rik van Riel
2001-03-18 12:33                                 ` Mike Galbraith
2001-03-14  1:59           ` system call for process information? john slee
2001-03-14 19:53   ` Szabolcs Szakacsits
2001-03-14 19:55     ` Alexander Viro
2001-03-14 20:23       ` Szabolcs Szakacsits
2001-03-14 20:21         ` Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2001-03-18  9:34 changing mm->mmap_sem (was: Re: system call for process information?) Manfred Spraul
2001-03-18 10:56 ` Rik van Riel
2001-03-19 12:54 ` Stephen C. Tweedie
     [not found] <Pine.LNX.4.33.0103181407520.1426-100000@mikeg.weiden.de>
2001-03-18 14:43 ` Rik van Riel
2001-03-18 18:13   ` Linus Torvalds
     [not found] <200103181813.KAA22153@penguin.transmeta.com>
2001-03-18 20:59 ` Rik van Riel
2001-03-19  1:21   ` Linus Torvalds
2001-03-19  2:59     ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010316094918.F30889@redhat.com \
    --to=sct@redhat.com \
    --cc=bcrl@redhat.com \
    --cc=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox