All of lore.kernel.org
 help / color / mirror / Atom feed
From: Topi Miettinen <toiwoton@gmail.com>
To: linux-man@vger.kernel.org, alx.manpages@gmail.com,
	mtk.manpages@gmail.com
Cc: linux-mm@vger.kernel.org, Topi Miettinen <toiwoton@gmail.com>
Subject: [PATCH] mmap.2: ENOMEM possible when exceeding VA space
Date: Thu, 11 Nov 2021 20:04:17 +0200	[thread overview]
Message-ID: <20211111180417.8382-1-toiwoton@gmail.com> (raw)

A bit surprisingly, mmap(2) returns ENOMEM when the virtual address
space of the CPU is exceeded.

The expectation could be EINVAL instead ("We don't like _addr_,
length, or offset (e.g., they are _too large_, or not aligned on a
page boundary)").

This is demonstrated with the following program:

 #include <stdio.h>
 #include <sys/mman.h>

 int main(void) {
 	for (int i = 12; i < 64; i++) {
		void *addr = mmap((void *)(1UL << i), 4096, PROT_NONE,
				  MAP_ANON | MAP_FIXED_NOREPLACE | MAP_PRIVATE,
				  -1, 0);
		if (addr == MAP_FAILED)
			fprintf(stderr, "mmap %lx: %m\n", (1UL << i));
		continue;
		munmap(addr, 4096);
	}
 }

It gives the following output when running on CPU with 48 bit VA
space:

mmap 800000000000: Cannot allocate memory
mmap 1000000000000: Cannot allocate memory
mmap 2000000000000: Cannot allocate memory
mmap 4000000000000: Cannot allocate memory
mmap 8000000000000: Cannot allocate memory
mmap 10000000000000: Cannot allocate memory
mmap 20000000000000: Cannot allocate memory
mmap 40000000000000: Cannot allocate memory
mmap 80000000000000: Cannot allocate memory
mmap 100000000000000: Cannot allocate memory
mmap 200000000000000: Cannot allocate memory
mmap 400000000000000: Cannot allocate memory
mmap 800000000000000: Cannot allocate memory
mmap 1000000000000000: Cannot allocate memory
mmap 2000000000000000: Cannot allocate memory
mmap 4000000000000000: Cannot allocate memory
mmap 8000000000000000: Cannot allocate memory

Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
 man2/mmap.2 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/man2/mmap.2 b/man2/mmap.2
index 96b7444b0..59fd5c904 100644
--- a/man2/mmap.2
+++ b/man2/mmap.2
@@ -603,6 +603,11 @@ limit, described in
 .BR getrlimit (2),
 would have been exceeded.
 .TP
+.B ENOMEM
+We don't like
+.IR addr ,
+because it exceeds the virtual address space of the CPU.
+.TP
 .B EOVERFLOW
 On 32-bit architecture together with the large file extension
 (i.e., using 64-bit
-- 
2.33.0


             reply	other threads:[~2021-11-11 18:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 18:04 Topi Miettinen [this message]
2021-11-22 16:15 ` [PATCH] mmap.2: ENOMEM possible when exceeding VA space Jakub Wilk
2021-11-22 17:16   ` Alejandro Colomar (man-pages)
2021-11-22 17:00 ` Alejandro Colomar (man-pages)

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=20211111180417.8382-1-toiwoton@gmail.com \
    --to=toiwoton@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=mtk.manpages@gmail.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.