linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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/

  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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox