From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: Christoph Rohland <hans-christoph.rohland@sap.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
torvalds@transmeta.com, Kanoj Sarcar <kanoj@google.engr.sgi.com>
Subject: Re: [RFC] [RFT] Shared /dev/zero mmaping feature
Date: Tue, 29 Feb 2000 10:30:12 -0800 (PST) [thread overview]
Message-ID: <200002291830.KAA65568@google.engr.sgi.com> (raw)
In-Reply-To: <qwwem9wnus3.fsf@sap.com> from "Christoph Rohland" at Feb 29, 2000 11:54:36 AM
> Why do you use this special zero_id stuff? It clutters up the whole
> code.
The zero_id stuff is required to differentiate between the struct
shmid_kernel of a "real" shared memory segment and one that
represents a /dev/zero mapping. This is used in shm_swap_core(),
for accounting purposes, but that can be changed by adding a
new flag to shm_swap_core. The more important use is in
shm_nopage().
>
> If you would simply open a normal shm segment with key IPC_PRIVATE and
> directly remove it nobody can attach to it and it will be released on
> exit and everything. No special handling needed any more. BTW that's
> exectly what we do in user space to circumvent the missing MAP_ANON |
> MAP_SHARED.
Would this need to be done for each /dev/zero mapping? If so, then
I prefer the way the code is right now, since the interference with
"real" shared memory is minimal. I was also trying to look for a way
to prevent the zshmid_kernel hacks in shmat/shmctl (including setting
strict permissions), but couldn't come up with one ... Tell me in more
detail what you are suggesting here.
>
> I would also prefer to be able to see the allocated segments with the
> ipc* commands.
>
I do not believe there is any good reason to expose the special shared
memory segment used as a place holder for all /dev/zero mappings to users
via ipc* commands. This special segment exists only because we
want to reduce kernel code duplication, and all the zshmid_kernel/
zero_id checks just make sure that regular shared memory works
pretty much the way it did before. (One thing I am unhappy about
is that this special segment eats up a shm id, but that's probably
not too bad).
Thanks.
Kanoj
--
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/
next prev parent reply other threads:[~2000-02-29 18:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-25 23:08 [RFC] [RFT] Shared /dev/zero mmaping feature Kanoj Sarcar
2000-02-26 16:38 ` Linus Torvalds
2000-02-26 21:47 ` Kanoj Sarcar
2000-02-29 10:54 ` Christoph Rohland
2000-02-29 18:30 ` Kanoj Sarcar [this message]
2000-03-01 12:08 ` Christoph Rohland
2000-03-01 17:34 ` Kanoj Sarcar
2000-03-01 17:55 ` Christoph Rohland
2000-03-01 18:18 ` Kanoj Sarcar
2000-03-01 19:42 ` Christoph Rohland
2000-03-01 20:09 ` Kanoj Sarcar
2000-03-06 22:43 ` Stephen C. Tweedie
2000-03-06 23:01 ` Kanoj Sarcar
2000-03-08 12:02 ` Christoph Rohland
2000-03-08 17:51 ` Kanoj Sarcar
2000-03-08 18:35 ` Christoph Rohland
2000-03-08 18:48 ` Linus Torvalds
2000-03-08 18:57 ` Kanoj Sarcar
2000-03-09 18:15 ` Christoph Rohland
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=200002291830.KAA65568@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=hans-christoph.rohland@sap.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.