From: "Stephen C. Tweedie" <sct@redhat.com>
To: James Simmons <jsimmons@edgeglobal.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-mm@kvack.org
Subject: Re: mm->mmap_sem
Date: Fri, 24 Sep 1999 19:09:02 +0100 (BST) [thread overview]
Message-ID: <14315.48702.873172.788668@dukat.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.9909241040460.12262-100000@imperial.edgeglobal.com>
Hi,
On Fri, 24 Sep 1999 10:59:31 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:
> Does this mean while one process is in the act of mlocking a memory
> region another process can actually change the contents of that memory?
Yes. The semaphore only protects against changes to the mmap lists and
page tables. It does not protect memory itself. On a multi-processor
machine, the only way the kernel on one CPU can prevent the contents of
a page from being modified by a process on another CPU is to forcibly
revoke all read-write mappings to that page.
>> > Will this semaphore protect this region? In a SMP machine same
>> > thing. What kind of protect does this semaphore provide? Does it
>> > prevent other process from doing anything to the memory.
>>
>> No.
> I obtained this idea from do_page_fault. This function is called from a
> interrupt when a process actually tries to access memory correct?
No, it is only called when a process tries to access memory which is not
currently in the process's page tables. If the page is already mapped,
then there is no page fault. Otherwise you'd be doing massive amounts
of kernel work for every byte of data accessed by every process.
--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://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-09-24 18:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-22 21:02 mm->mmap_sem James Simmons
1999-09-24 0:07 ` mm->mmap_sem Stephen C. Tweedie
1999-09-24 14:59 ` mm->mmap_sem James Simmons
1999-09-24 18:09 ` Stephen C. Tweedie [this message]
1999-09-25 1:24 ` mm->mmap_sem James Simmons
1999-09-25 14:55 ` mm->mmap_sem Andrea Arcangeli
1999-09-25 16:50 ` mm->mmap_sem James Simmons
1999-09-25 17:06 ` mm->mmap_sem Andrea Arcangeli
1999-09-26 1:19 ` mm->mmap_sem James Simmons
1999-09-26 14:07 ` mm->mmap_sem Andrea Arcangeli
1999-09-27 8:55 ` mm->mmap_sem Marcus Sundberg
1999-09-27 19:31 ` mm->mmap_sem James Simmons
1999-09-29 23:00 ` mm->mmap_sem Stephen C. Tweedie
1999-09-30 0:17 ` mm->mmap_sem James Simmons
1999-09-30 0:23 ` mm->mmap_sem Benjamin C.R. LaHaise
1999-09-30 14:59 ` mm->mmap_sem James Simmons
1999-09-30 15:15 ` mm->mmap_sem Benjamin C.R. LaHaise
1999-09-30 16:05 ` mm->mmap_sem James Simmons
1999-09-30 14:54 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 14:16 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 20:22 ` mm->mmap_sem James Simmons
1999-09-27 14:13 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 8:08 ` mm->mmap_sem Neil Conway
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=14315.48702.873172.788668@dukat.scot.redhat.com \
--to=sct@redhat.com \
--cc=jsimmons@edgeglobal.com \
--cc=linux-mm@kvack.org \
/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