[LTP] [PATCH v2] mmap_24-1: Change vm.max_map_count if needed

[LTP] [PATCH v2] mmap_24-1: Change vm.max_map_count if needed

[Martin Doucha]

If vm.max_map_count system parameter is too high, mmap24-1 may get
killed by OOM. Set the parameter to a reasonable low value so that
mmap() quickly fails as expected.

Signed-off-by: Martin Doucha <mdoucha@suse.cz>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
---

Changes since v1:
- Print warning if procfile cannot be opened
- Use fopen(..., "r") instead of "r+" in main()

 .../conformance/interfaces/mmap/24-1.c        | 37 ++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
index 6cc8349e1..49673d603 100644
--- a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
+++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
@@ -31,12 +31,42 @@
 #include <stdint.h>
 #include "posixtest.h"
 
+#define MAX_MAP_COUNT_PATH "/proc/sys/vm/max_map_count"
+#define MAP_COUNT_LIMIT 65530
+
+void proc_write_val(const char *path, size_t val)
+{
+	FILE *procfile;
+
+	procfile = fopen(path, "r+");
+
+	if (!procfile) {
+		printf("Warning: Could not open %s\n", path);
+		return;
+	}
+
+	fprintf(procfile, "%zu", val);
+	fclose(procfile);
+}
+
 int main(void)
 {
 	char tmpfname[256];
 	void *pa;
-	size_t len;
+	size_t len, max_map_count = 0;
 	int fd;
+	FILE *procfile;
+
+	/* Change vm.max_map_count to avoid OOM */
+	procfile = fopen(MAX_MAP_COUNT_PATH, "r");
+
+	if (procfile) {
+		fscanf(procfile, "%zu", &max_map_count);
+		fclose(procfile);
+	}
+
+	if (max_map_count > MAP_COUNT_LIMIT)
+		proc_write_val(MAX_MAP_COUNT_PATH, MAP_COUNT_LIMIT);
 
 	/* Size of the shared memory object */
 	size_t shm_size = 1024;
@@ -78,5 +108,10 @@ int main(void)
 
 	close(fd);
 	printf("Test FAILED: Did not get ENOMEM as expected\n");
+
+	/* Restore original vm.max_map_count */
+	if (max_map_count > MAP_COUNT_LIMIT)
+		proc_write_val(MAX_MAP_COUNT_PATH, max_map_count);
+
 	return PTS_FAIL;
 }
-- 
2.49.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v2] mmap_24-1: Change vm.max_map_count if needed

[Li Wang via ltp]

On Fri, May 9, 2025 at 7:32 PM Martin Doucha <mdoucha@suse.cz> wrote:
>
> If vm.max_map_count system parameter is too high, mmap24-1 may get
> killed by OOM. Set the parameter to a reasonable low value so that
> mmap() quickly fails as expected.
>
> Signed-off-by: Martin Doucha <mdoucha@suse.cz>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>
> Changes since v1:
> - Print warning if procfile cannot be opened
> - Use fopen(..., "r") instead of "r+" in main()
>
>  .../conformance/interfaces/mmap/24-1.c        | 37 ++++++++++++++++++-
>  1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> index 6cc8349e1..49673d603 100644
> --- a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> +++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c

As I pointed in the previous thread, we should update the code
comments to explicitly state that the failure is caused by exceeding
the maximum number of memory mappings (vm.max_map_count),
rather than overall memory exhaustion.

Without this clarification, readers may be misled by the current comments
and mistakenly assume that the code is intended to test total memory
exhaustion, which is not the case.

Anyway, patch itself looks good.
And I vote for merging this before a new release.

Reviewed-by: Li Wang <liwang@redhat.com>

> @@ -31,12 +31,42 @@
>  #include <stdint.h>
>  #include "posixtest.h"
>
> +#define MAX_MAP_COUNT_PATH "/proc/sys/vm/max_map_count"
> +#define MAP_COUNT_LIMIT 65530
> +
> +void proc_write_val(const char *path, size_t val)
> +{
> +       FILE *procfile;
> +
> +       procfile = fopen(path, "r+");
> +
> +       if (!procfile) {
> +               printf("Warning: Could not open %s\n", path);
> +               return;
> +       }
> +
> +       fprintf(procfile, "%zu", val);
> +       fclose(procfile);
> +}
> +
>  int main(void)
>  {
>         char tmpfname[256];
>         void *pa;
> -       size_t len;
> +       size_t len, max_map_count = 0;
>         int fd;
> +       FILE *procfile;
> +
> +       /* Change vm.max_map_count to avoid OOM */
> +       procfile = fopen(MAX_MAP_COUNT_PATH, "r");
> +
> +       if (procfile) {
> +               fscanf(procfile, "%zu", &max_map_count);
> +               fclose(procfile);
> +       }
> +
> +       if (max_map_count > MAP_COUNT_LIMIT)
> +               proc_write_val(MAX_MAP_COUNT_PATH, MAP_COUNT_LIMIT);
>
>         /* Size of the shared memory object */
>         size_t shm_size = 1024;
> @@ -78,5 +108,10 @@ int main(void)
>
>         close(fd);
>         printf("Test FAILED: Did not get ENOMEM as expected\n");
> +
> +       /* Restore original vm.max_map_count */
> +       if (max_map_count > MAP_COUNT_LIMIT)
> +               proc_write_val(MAX_MAP_COUNT_PATH, max_map_count);
> +
>         return PTS_FAIL;
>  }
> --
> 2.49.0
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v2] mmap_24-1: Change vm.max_map_count if needed

[Petr Vorel]

Hi all,

merged, thank you!
@Li, please merge your follow up fixing comment.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH] mmap_24-1: update code comments

[Li Wang via ltp]

Follow-up: mmap_24-1: Change vm.max_map_count if needed
Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Martin Doucha <mdoucha@suse.cz>
---

Notes:
    This patch is based on Martin's vm.max_map_count change, to make
    everything is clear enough from the code to comments.

 .../conformance/interfaces/mmap/24-1.c        | 20 +++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
index 49673d603..8aebdba61 100644
--- a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
+++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
@@ -7,15 +7,23 @@
  * source tree.
  *
  * The mmap() function shall fail if:
- * [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len)
+ * [ENOMEM] MAP_FIXED was specified, and the range [addr, addr+len)
  * exceeds that allowed for the address space of a process;
- * or, if MAP_FIXED was not specified and
- * there is insufficient room in the address space to effect the mapping.
+ * or, if MAP_FIXED was not specified and there is insufficient room
+ * in the address space to effect the mapping;
+ * or, if the process exceeds the maximum number of allowed memory mappings
+ * (as defined by /proc/sys/vm/max_map_count).
  *
  * Test Steps:
- * 1. In a very long loop, keep mapping a shared memory object,
- *    until there this insufficient room in the address space;
- * 3. Should get ENOMEM.
+ * 1. In a very long loop, continuously map a shared memory object without
+ *    unmapping previous ones.
+ * 2. The loop continues until mmap() fails with ENOMEM.
+ *
+ * Note:
+ * This failure may occur due to either exhausting the process's
+ * virtual address space, or hitting the system-wide limit on
+ * the number of memory mappings (especially on systems with large RAM).
+ *
  */
 
 #include <stdio.h>
-- 
2.49.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] mmap_24-1: update code comments

[Martin Doucha]

Hi,
thank you.

Reviewed-by: Martin Doucha <mdoucha@suse.cz>

On 09. 05. 25 14:34, Li Wang wrote:
> Follow-up: mmap_24-1: Change vm.max_map_count if needed
> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: Martin Doucha <mdoucha@suse.cz>
> ---
> 
> Notes:
>      This patch is based on Martin's vm.max_map_count change, to make
>      everything is clear enough from the code to comments.
> 
>   .../conformance/interfaces/mmap/24-1.c        | 20 +++++++++++++------
>   1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> index 49673d603..8aebdba61 100644
> --- a/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> +++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> @@ -7,15 +7,23 @@
>    * source tree.
>    *
>    * The mmap() function shall fail if:
> - * [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len)
> + * [ENOMEM] MAP_FIXED was specified, and the range [addr, addr+len)
>    * exceeds that allowed for the address space of a process;
> - * or, if MAP_FIXED was not specified and
> - * there is insufficient room in the address space to effect the mapping.
> + * or, if MAP_FIXED was not specified and there is insufficient room
> + * in the address space to effect the mapping;
> + * or, if the process exceeds the maximum number of allowed memory mappings
> + * (as defined by /proc/sys/vm/max_map_count).
>    *
>    * Test Steps:
> - * 1. In a very long loop, keep mapping a shared memory object,
> - *    until there this insufficient room in the address space;
> - * 3. Should get ENOMEM.
> + * 1. In a very long loop, continuously map a shared memory object without
> + *    unmapping previous ones.
> + * 2. The loop continues until mmap() fails with ENOMEM.
> + *
> + * Note:
> + * This failure may occur due to either exhausting the process's
> + * virtual address space, or hitting the system-wide limit on
> + * the number of memory mappings (especially on systems with large RAM).
> + *
>    */
>   
>   #include <stdio.h>


-- 
Martin Doucha   mdoucha@suse.cz
SW Quality Engineer
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] mmap_24-1: update code comments

[Petr Vorel]

Hi Li,

> Follow-up: mmap_24-1: Change vm.max_map_count if needed

Thanks!
...
> +++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> @@ -7,15 +7,23 @@
>   * source tree.
>   *
>   * The mmap() function shall fail if:
> - * [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len)
> + * [ENOMEM] MAP_FIXED was specified, and the range [addr, addr+len)
>   * exceeds that allowed for the address space of a process;
> - * or, if MAP_FIXED was not specified and
> - * there is insufficient room in the address space to effect the mapping.
> + * or, if MAP_FIXED was not specified and there is insufficient room
> + * in the address space to effect the mapping;
> + * or, if the process exceeds the maximum number of allowed memory mappings
> + * (as defined by /proc/sys/vm/max_map_count).
>   *
>   * Test Steps:
> - * 1. In a very long loop, keep mapping a shared memory object,
> - *    until there this insufficient room in the address space;
> - * 3. Should get ENOMEM.
> + * 1. In a very long loop, continuously map a shared memory object without
> + *    unmapping previous ones.
> + * 2. The loop continues until mmap() fails with ENOMEM.
> + *
> + * Note:
> + * This failure may occur due to either exhausting the process's
> + * virtual address space, or hitting the system-wide limit on
> + * the number of memory mappings (especially on systems with large RAM).
> + *
nit: please remove before commit this blank line.

Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

>   */

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] mmap_24-1: update code comments

[Li Wang via ltp]

On Mon, May 12, 2025 at 9:26 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi Li,
>
> > Follow-up: mmap_24-1: Change vm.max_map_count if needed
>
> Thanks!
> ...
> > +++ b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-1.c
> > @@ -7,15 +7,23 @@
> >   * source tree.
> >   *
> >   * The mmap() function shall fail if:
> > - * [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len)
> > + * [ENOMEM] MAP_FIXED was specified, and the range [addr, addr+len)
> >   * exceeds that allowed for the address space of a process;
> > - * or, if MAP_FIXED was not specified and
> > - * there is insufficient room in the address space to effect the
> mapping.
> > + * or, if MAP_FIXED was not specified and there is insufficient room
> > + * in the address space to effect the mapping;
> > + * or, if the process exceeds the maximum number of allowed memory
> mappings
> > + * (as defined by /proc/sys/vm/max_map_count).
> >   *
> >   * Test Steps:
> > - * 1. In a very long loop, keep mapping a shared memory object,
> > - *    until there this insufficient room in the address space;
> > - * 3. Should get ENOMEM.
> > + * 1. In a very long loop, continuously map a shared memory object
> without
> > + *    unmapping previous ones.
> > + * 2. The loop continues until mmap() fails with ENOMEM.
> > + *
> > + * Note:
> > + * This failure may occur due to either exhausting the process's
> > + * virtual address space, or hitting the system-wide limit on
> > + * the number of memory mappings (especially on systems with large RAM).
> > + *
> nit: please remove before commit this blank line.
>

Ah sure, merged as you suggested.
Thanks!

-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp