MAP_NORESERVE with MAP_SHARED

MAP_NORESERVE with MAP_SHARED

[David Mosberger]

Is there a good reason why the MAP_NORESERVE flag is ignored when
MAP_SHARED is specified?  (Hint: it's the call to vm_enough_memory()
in shmem_file_setup() that's causing MAP_NORESERVE to be ignored.)

	--david
--
Interested in learning more about IA-64 Linux?  Try http://www.lia64.org/book/

Re: MAP_NORESERVE with MAP_SHARED

[Alan Cox]

On Fri, 2002-07-12 at 21:39, David Mosberger wrote:
> Is there a good reason why the MAP_NORESERVE flag is ignored when
> MAP_SHARED is specified?  (Hint: it's the call to vm_enough_memory()
> in shmem_file_setup() that's causing MAP_NORESERVE to be ignored.)

In no overcommit mode MAP_NORESERVE is never honoured. In conventional
overcommit mode I may have broken something between base and -ac. Which
bit of the code are you looking at ?

Re: MAP_NORESERVE with MAP_SHARED

[Robert Love]

On Fri, 2002-07-12 at 15:15, Alan Cox wrote:

> In no overcommit mode MAP_NORESERVE is never honoured. In conventional
> overcommit mode I may have broken something between base and -ac. Which
> bit of the code are you looking at ?

As far as I can tell, the code is correct as you say and MAP_NORESERVE
is only not honored in the strict overcommit modes...

	Robert Love

Re: MAP_NORESERVE with MAP_SHARED

[David Mosberger]

>>>>> On 12 Jul 2002 23:15:02 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> said:

  Alan> On Fri, 2002-07-12 at 21:39, David Mosberger wrote:
  >> Is there a good reason why the MAP_NORESERVE flag is ignored when
  >> MAP_SHARED is specified?  (Hint: it's the call to vm_enough_memory()
  >> in shmem_file_setup() that's causing MAP_NORESERVE to be ignored.)

  Alan> In no overcommit mode MAP_NORESERVE is never honoured. In conventional
  Alan> overcommit mode I may have broken something between base and -ac. Which
  Alan> bit of the code are you looking at ?

2.4.18, though as far as I looked, the latest 2.5 has the same behavior.
Specifically, in do_mmap_pgoff() we have:

	/* Private writable mapping? Check memory availability.. */
	if ((vm_flags & (VM_SHARED | VM_WRITE)) == VM_WRITE &&
	    !(flags & MAP_NORESERVE)				 &&
	    !vm_enough_memory(len >> PAGE_SHIFT))
		return -ENOMEM;

and in shmem_file_setup() we have:

	if (!vm_enough_memory((size) >> PAGE_CACHE_SHIFT))
		return ERR_PTR(-ENOMEM);

So, if we don't have MAP_SHARED (first case), MAP_NORESERVE is
honored, whereas with MAP_SHARED (second case), MAP_NORESERVE is
ignored.

	--david

Re: MAP_NORESERVE with MAP_SHARED

[Hugh Dickins]

On Fri, 12 Jul 2002, David Mosberger wrote:
> Is there a good reason why the MAP_NORESERVE flag is ignored when
> MAP_SHARED is specified?  (Hint: it's the call to vm_enough_memory()
> in shmem_file_setup() that's causing MAP_NORESERVE to be ignored.)

Normally MAP_NORESERVE has no effect when MAP_SHARED is specfied,
since mods will be written out to file, so don't need memory+swap.

You're looking at the special case of a tmpfs file (actually,
the even more special case of an internally created tmpfs file),
which of course needs memory+swap, since it has no disk backing.

But (for whatever this jesuitical argument is worth: probably not
much) it's the object which needs that memory+swap, not the shared
mapping of that object.  Should MAP_NORESERVE apply to the object
in this case?  At this moment, I'm uncertain (but since the object
has been created internally purely to provide that mapping, it may
be unhelpful to deny it).

You were writing of mainline 2.4 or 2.5, where reservation isn't
taken seriously anyway.  It becomes more serious in the -ac tree,
or with rml's patch, where it's more than a question of MAP_NORESERVE.
Check /proc/meminfo Committed_AS and you'll find we reserve twice the
size of a shared anonymous mapping (in this tree, do_mmap_pgoff
is calling vm_enough_memory even when MAP_SHARED but file NULL,
then it's called again as you found in shmem_file_setup).
But at least the numbers do balance out when unmapping.

I'll take another look at this in a few days, right now I'm a
little confused by it.  Just dropping check from shmem_file_setup
won't be the answer, I believe SysV IPC SHM needs it, and in
ac/rml it's needed to balance removal of the object.
Thanks for raising the issue.

Hugh