LKML Archive on
help / color / mirror / Atom feed
From: David Howells <>
To: Hugh Dickins <>
Cc:, Robin Holt <>,
	"Kawai, Hidehiro" <>,
	Andrew Morton <>,
	kernel list <>,
	Pavel Machek <>, Alan Cox <>,
	Masami Hiramatsu <>,
	sugita <>,
	Satoshi OSHIMA <>,, Robin Getz <>
Subject: Re: Move to unshared VMAs in NOMMU mode?
Date: Thu, 15 Mar 2007 22:47:05 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hugh Dickins <> wrote:

> But if "the SYSV SHM problem" you mention at the beginning
> is just the "nattch" problem you mention at the end, I doubt
> that's worth such a redesign as you're considering here.

Yes, as far as I know that's the problem.  nattch is available to userspace and
seems to misbehave as far as userspace programs are concerned (I think the
program sees that it is 1 and assumes itself to be the last user).

> Actually, I'm rather surprised SHM needs any such nattch count,
> I'd expect it to deducible from file->f_count and mode&SHM_DEST
> (but haven't investigated whether that really works out at all).

Ummm...  Currently file->f_count doesn't count the number of shmats because the
VMAs are shared.  If they are no longer shared then the problem goes away.

There may be several VMLs for a particular process pointing to a VMA.

sys_shmdt() doesn't malfunction because it's not possible to split a VMA in
NOMMU mode, and so the whole VMA must match.

Actually, looking carefully at it, it might go wrong it someone does shmat(),
munmap(), shmdt().  do_munmap(), however, protects against too many munmaps (in
whatever form they're issued).

> If you just need a little CONFIG_MMU in ipc/shm.c to solve your
> problem, I don't think more is justified.

Hmmm... I'm not sure it's quite that simple.  SYSV SHM is provided by a chain
of shm -> tiny-shmem -> ramfs.  The mapping is actually managed by ramfs.

> Your struct vm_region idea does look more to my taste than what
> you presently have; yet if you pursue it, I think it would just
> make divergence worse wouldn't it?  NOMMU wanting vma to contain
> a pointer to vm_region, MMU wanting vm_region embedded in vma.

That bit of divergence is, in effect, already there.  In NOMMU-mode the VMA
owns the backing store; in MMU-mode it does not.  This would, at least, rectify
that: fixing it would mean that the backing store is no longer owned by the
VMA, and would permit more flexibility in overlapping mappings.

> I don't really understand why NOMMU chooses to share vmas, or
> vm_regions, rather than just sharing the data which they indicate.

Where would that data be?  How do you keep track of it?  How do you know when
to deallocate it?

I have considered co-opting the pagecache attached to the mapped inode (which
is exactly how I do shared-writable mappings on ramfs), but that only works for
shared mappings.  I still have to have a way to handle unshareable mappings.
At the moment, they're both the same way (unless overridden by the driver/fs),
and I just share the VMA.

> Just because you can use less memory that way?

That's one consideration.  The other is that it makes management of these
chunks of data simpler.  If the memory isn't attached to the VMA then it must
be managed in some other manner.


  parent reply	other threads:[~2007-03-15 22:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 13:34 [PATCH 0/4] coredump: core dump masking support v3 Kawai, Hidehiro
2007-02-16 13:39 ` [PATCH 1/4] coredump: add an interface to control the core dump routine Kawai, Hidehiro
2007-02-16 13:40 ` [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory Kawai, Hidehiro
2007-02-16 13:41 ` [PATCH 3/4] coredump: ELF-FDPIC: " Kawai, Hidehiro
2007-02-16 13:42 ` [PATCH 4/4] coredump: documentation for proc entry Kawai, Hidehiro
2007-02-16 15:05 ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory David Howells
2007-02-16 16:50   ` Robin Holt
2007-02-16 20:09   ` David Howells
2007-03-02 16:55     ` Hugh Dickins
2007-03-03 14:10     ` David Howells
2007-03-05 19:04       ` Hugh Dickins
2007-03-06 18:13       ` David Howells
2007-03-09 14:12       ` Move to unshared VMAs in NOMMU mode? David Howells
2007-03-12 20:50         ` Robin Getz
2007-03-13 10:14         ` David Howells
2007-03-15 21:20         ` Hugh Dickins
2007-03-15 22:47         ` David Howells [this message]
2007-03-19 19:23           ` Eric W. Biederman
2007-03-20 11:06           ` David Howells
2007-03-20 16:48             ` Eric W. Biederman
2007-03-20 19:12             ` David Howells
2007-03-20 19:51             ` David Howells
2007-03-21 16:11             ` David Howells
2007-03-03 14:25     ` [PATCH] NOMMU: Hide vm_mm in NOMMU mode David Howells
2007-02-20  9:45   ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory Kawai, Hidehiro
2007-02-20 10:58   ` David Howells
2007-02-20 12:56     ` Robin Holt
2007-02-21 10:00     ` Kawai, Hidehiro
2007-02-21 11:33     ` David Howells
2007-02-21 11:54       ` Robin Holt
2007-02-22  5:33         ` Kawai, Hidehiro
2007-02-22 11:47         ` David Howells
2007-02-16 15:08 ` [PATCH 0/4] coredump: core dump masking support v3 David Howells
2007-02-20  9:48   ` Kawai, Hidehiro
2007-02-24  3:32 ` Markus Gutschke
2007-02-24 11:39   ` Pavel Machek
2007-03-01 12:35   ` Kawai, Hidehiro
2007-03-01 18:16     ` Markus Gutschke
2007-02-24 10:02 ` David Howells
2007-02-24 20:01   ` Markus Gutschke
2007-02-26 11:49   ` David Howells
2007-02-26 12:01     ` Pavel Machek
2007-02-26 12:42     ` David Howells

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).