[LTP] [PATCH 0/3] mmap testing suite to cover MAP_32BIT

[LTP] [PATCH 0/3] mmap testing suite to cover MAP_32BIT

[Andrea Cervesato]

Create two new tests to verify MAP_32BIT functionality:

- mmap23: verify if it fails with invalid parameters
- mmap24: verify bondaries of the allocation

Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
---
Andrea Cervesato (3):
      lapi/mmap: add MAP_32BIT fallback
      mmap23: add test for MAP_32BIT oversized mapping
      mmap24: add test for MAP_32BIT address limit

 include/lapi/mmap.h                       |  4 ++
 runtest/syscalls                          |  2 +
 testcases/kernel/syscalls/mmap/.gitignore |  2 +
 testcases/kernel/syscalls/mmap/mmap23.c   | 36 ++++++++++++
 testcases/kernel/syscalls/mmap/mmap24.c   | 96 +++++++++++++++++++++++++++++++
 5 files changed, 140 insertions(+)
---
base-commit: 3c0271a307bd765c2fd652c325762a90ddf5d46f
change-id: 20260827-mmap_32bit_coverage-09a22407aa39

Best regards,
--  
Andrea Cervesato <andrea.cervesato@suse.com>


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

[LTP] [PATCH 1/3] lapi/mmap: add MAP_32BIT fallback

[Andrea Cervesato]

From: Andrea Cervesato <andrea.cervesato@suse.com>

Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
---
 include/lapi/mmap.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/lapi/mmap.h b/include/lapi/mmap.h
index 3908310f4..f20eb3bd5 100644
--- a/include/lapi/mmap.h
+++ b/include/lapi/mmap.h
@@ -91,6 +91,10 @@
 # define MAP_DROPPABLE 0x08
 #endif
 
+#ifndef MAP_32BIT
+# define MAP_32BIT 0x40
+#endif
+
 #ifndef MREMAP_DONTUNMAP
 # define MREMAP_DONTUNMAP 4
 #endif

-- 
2.51.0


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

Re: [LTP] lapi/mmap: add MAP_32BIT fallback

[linuxtestproject.agent]

Hi Andrea,

On Aug 28, 2026, Andrea Cervesato wrote:
> lapi/mmap: add MAP_32BIT fallback

--- [PATCH 3/3] ---

>  * - Verify that memory in each chunk is readable and writable
> [...]
> 		((char *)addr)[0] = 'a';
> 		((char *)addr)[CHUNK_SZ - 1] = 'z';

The algorithm says that each chunk is verified to be both readable and
writable, but these statements only write to the mapping. Could the test
read and compare the stored bytes, or should the readability claim be
removed?

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

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

Re: [LTP] lapi/mmap: add MAP_32BIT fallback

[Andrea Cervesato via ltp]

> On Aug 28, 2026, Andrea Cervesato wrote:
> > lapi/mmap: add MAP_32BIT fallback
> 
> --- [PATCH 3/3] ---
> 
> >  * - Verify that memory in each chunk is readable and writable
> > [...]
> > 		((char *)addr)[0] = 'a';
> > 		((char *)addr)[CHUNK_SZ - 1] = 'z';
> 
> The algorithm says that each chunk is verified to be both readable and
> writable, but these statements only write to the mapping. Could the test
> read and compare the stored bytes, or should the readability claim be
> removed?

this simply requires:

* - Touch first and last byte of each chunk to ensure pages are writable

will add before merge.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

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

Re: [LTP] [PATCH 1/3] lapi/mmap: add MAP_32BIT fallback

[Petr Vorel]

Hi Andrea,

> +++ b/include/lapi/mmap.h
> @@ -91,6 +91,10 @@
>  # define MAP_DROPPABLE 0x08
>  #endif

> +#ifndef MAP_32BIT
> +# define MAP_32BIT 0x40

I know you guard the tests with .supported_archs to x86_64, but even that
wouldn't be safer to define 0x40 only for x86_64?

#ifndef MAP_32BIT
# if defined __i386__ || defined(__x86_64__)
#  define MAP_32BIT 0x40
# else
#  define MAP_32BIT 0
# endif
#endif

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

Kind regards,
Petr

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

Re: [LTP] [PATCH 1/3] lapi/mmap: add MAP_32BIT fallback

[Petr Vorel]

> Hi Andrea,

> > +++ b/include/lapi/mmap.h
> > @@ -91,6 +91,10 @@
> >  # define MAP_DROPPABLE 0x08
> >  #endif

> > +#ifndef MAP_32BIT
> > +# define MAP_32BIT 0x40

> I know you guard the tests with .supported_archs to x86_64, but even that
> wouldn't be safer to define 0x40 only for x86_64?

> #ifndef MAP_32BIT
> # if defined __i386__ || defined(__x86_64__)
OK, only #ifdef __x86_64__

Kind regards,
Petr

> #  define MAP_32BIT 0x40
> # else
> #  define MAP_32BIT 0
> # endif
> #endif

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

> Kind regards,
> Petr

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

[LTP] [PATCH 2/3] mmap23: add test for MAP_32BIT oversized mapping

[Andrea Cervesato]

From: Andrea Cervesato <andrea.cervesato@suse.com>

Add a test verifying that mmap() with the MAP_32BIT flag fails
with ENOMEM when requesting a mapping of size >= 2GB, since it
cannot fit within the first 2GB of address space.

Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
---
 runtest/syscalls                          |  1 +
 testcases/kernel/syscalls/mmap/.gitignore |  1 +
 testcases/kernel/syscalls/mmap/mmap23.c   | 36 +++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/runtest/syscalls b/runtest/syscalls
index 737c63e31..a264f42c8 100644
--- a/runtest/syscalls
+++ b/runtest/syscalls
@@ -890,6 +890,7 @@ mmap20 mmap20
 mmap21_01 mmap21 -m 1
 mmap21_02 mmap21
 mmap22 mmap22
+mmap23 mmap23
 
 modify_ldt01 modify_ldt01
 modify_ldt02 modify_ldt02
diff --git a/testcases/kernel/syscalls/mmap/.gitignore b/testcases/kernel/syscalls/mmap/.gitignore
index 075be933d..dd332e9a1 100644
--- a/testcases/kernel/syscalls/mmap/.gitignore
+++ b/testcases/kernel/syscalls/mmap/.gitignore
@@ -19,3 +19,4 @@
 /mmap20
 /mmap21
 /mmap22
+/mmap23
diff --git a/testcases/kernel/syscalls/mmap/mmap23.c b/testcases/kernel/syscalls/mmap/mmap23.c
new file mode 100644
index 000000000..4eb7bf6e9
--- /dev/null
+++ b/testcases/kernel/syscalls/mmap/mmap23.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 SUSE LLC Andrea Cervesato <andrea.cervesato@suse.com>
+ */
+
+/*\
+ * Verify that :manpage:`mmap(2)` with the MAP_32BIT flag fails with ENOMEM
+ * when requesting a mapping of size >= 2GB, since it cannot fit within the
+ * first 2GB of address space.
+ *
+ * MAP_32BIT is supported only on x86-64 for 64-bit programs.
+ */
+
+#include "tst_test.h"
+#include "lapi/mmap.h"
+
+#define MAP_SZ (2UL * TST_GB)
+
+static void run(void)
+{
+	TST_EXP_FAIL_PTR_VOID(mmap(NULL, MAP_SZ, PROT_READ | PROT_WRITE,
+				   MAP_PRIVATE | MAP_ANONYMOUS | MAP_32BIT, -1, 0),
+			      ENOMEM,
+			      "mmap(2GB) with MAP_32BIT");
+
+	if (TST_RET_PTR != MAP_FAILED)
+		SAFE_MUNMAP(TST_RET_PTR, MAP_SZ);
+}
+
+static struct tst_test test = {
+	.test_all = run,
+	.supported_archs = (const char *const []){
+		"x86_64",
+		NULL
+	},
+};

-- 
2.51.0


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

Re: [LTP] [PATCH 2/3] mmap23: add test for MAP_32BIT oversized mapping

[Petr Vorel]

Hi Andrea,

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

...
> +++ b/testcases/kernel/syscalls/mmap/mmap23.c
...
> +/*\
> + * Verify that :manpage:`mmap(2)` with the MAP_32BIT flag fails with ENOMEM
> + * when requesting a mapping of size >= 2GB, since it cannot fit within the
> + * first 2GB of address space.
> + *
> + * MAP_32BIT is supported only on x86-64 for 64-bit programs.
> + */
> +
> +#include "tst_test.h"
> +#include "lapi/mmap.h"
> +
> +#define MAP_SZ (2UL * TST_GB)

Interesting enough, it works on 1GB as well:

#define MAP_SZ (1UL * TST_GB)

Actually the minimum working memory on my system is 1001 MB (1001UL * TST_MB)

Kind regards,
Petr

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

[LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Andrea Cervesato]

From: Andrea Cervesato <andrea.cervesato@suse.com>

Add a test verifying that mmap() with the MAP_32BIT flag restricts
mappings to the first 2GB of address space and fails with ENOMEM
when the 32-bit address space is exhausted without falling back to
higher addresses.

Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
---
 runtest/syscalls                          |  1 +
 testcases/kernel/syscalls/mmap/.gitignore |  1 +
 testcases/kernel/syscalls/mmap/mmap24.c   | 96 +++++++++++++++++++++++++++++++
 3 files changed, 98 insertions(+)

diff --git a/runtest/syscalls b/runtest/syscalls
index a264f42c8..ef235668e 100644
--- a/runtest/syscalls
+++ b/runtest/syscalls
@@ -891,6 +891,7 @@ mmap21_01 mmap21 -m 1
 mmap21_02 mmap21
 mmap22 mmap22
 mmap23 mmap23
+mmap24 mmap24
 
 modify_ldt01 modify_ldt01
 modify_ldt02 modify_ldt02
diff --git a/testcases/kernel/syscalls/mmap/.gitignore b/testcases/kernel/syscalls/mmap/.gitignore
index dd332e9a1..f072e7f64 100644
--- a/testcases/kernel/syscalls/mmap/.gitignore
+++ b/testcases/kernel/syscalls/mmap/.gitignore
@@ -20,3 +20,4 @@
 /mmap21
 /mmap22
 /mmap23
+/mmap24
diff --git a/testcases/kernel/syscalls/mmap/mmap24.c b/testcases/kernel/syscalls/mmap/mmap24.c
new file mode 100644
index 000000000..50de620f4
--- /dev/null
+++ b/testcases/kernel/syscalls/mmap/mmap24.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 SUSE LLC Andrea Cervesato <andrea.cervesato@suse.com>
+ */
+
+/*\
+ * Verify that :manpage:`mmap(2)` with the MAP_32BIT flag restricts all mappings
+ * to the first 2GB of the process address space (< 0x80000000).
+ *
+ * MAP_32BIT is supported only on x86-64 for 64-bit programs.
+ *
+ * [Algorithm]
+ *
+ * - Repeatedly call mmap() allocating 32MB chunks with MAP_32BIT until ENOMEM
+ * - Verify that every returned address satisfies (addr + size) <= 0x80000000
+ * - Verify that memory in each chunk is readable and writable
+ * - Verify that at least one chunk was mapped and failure errno is ENOMEM
+ * - Unmap all allocated chunks in cleanup
+ */
+
+#include "tst_test.h"
+#include "lapi/mmap.h"
+
+#define ADDR_LIMIT 0x80000000UL
+#define CHUNK_SZ (32UL * TST_MB)
+#define MAX_CHUNKS 64
+
+static void *addrs[MAX_CHUNKS];
+static size_t num_chunks;
+
+static void cleanup(void)
+{
+	size_t i;
+
+	for (i = 0; i < num_chunks; i++) {
+		if (addrs[i]) {
+			SAFE_MUNMAP(addrs[i], CHUNK_SZ);
+			addrs[i] = NULL;
+		}
+	}
+	num_chunks = 0;
+}
+
+static void run(void)
+{
+	size_t i;
+	int failed_with_enomem = 0;
+
+	for (i = 0; i < MAX_CHUNKS; i++) {
+		void *addr = mmap(NULL, CHUNK_SZ, PROT_READ | PROT_WRITE,
+				  MAP_PRIVATE | MAP_ANONYMOUS | MAP_32BIT, -1, 0);
+
+		if (addr == MAP_FAILED) {
+			if (errno == ENOMEM)
+				failed_with_enomem = 1;
+			else
+				tst_res(TFAIL | TERRNO,
+					"mmap() failed with unexpected errno");
+			break;
+		}
+
+		if ((unsigned long)addr + CHUNK_SZ > ADDR_LIMIT) {
+			tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
+				addr, CHUNK_SZ);
+			addrs[num_chunks++] = addr;
+			cleanup();
+			return;
+		}
+
+		((char *)addr)[0] = 'a';
+		((char *)addr)[CHUNK_SZ - 1] = 'z';
+
+		addrs[num_chunks++] = addr;
+	}
+
+	if (!failed_with_enomem) {
+		tst_res(TFAIL, "32-bit address space was not exhausted");
+	} else if (!num_chunks) {
+		tst_res(TFAIL, "failed to map any chunk with MAP_32BIT");
+	} else {
+		tst_res(TPASS,
+			"Mapped %zu MB across %zu chunks within 2GB before ENOMEM",
+			(num_chunks * CHUNK_SZ) / TST_MB, num_chunks);
+	}
+
+	cleanup();
+}
+
+static struct tst_test test = {
+	.cleanup = cleanup,
+	.test_all = run,
+	.supported_archs = (const char *const []){
+		"x86_64",
+		NULL
+	},
+};

-- 
2.51.0


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

Re: [LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Cyril Hrubis]

Hi!
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Petr Vorel]

Hi Andrea,

> Add a test verifying that mmap() with the MAP_32BIT flag restricts
> mappings to the first 2GB of address space and fails with ENOMEM
> when the 32-bit address space is exhausted without falling back to
> higher addresses.

Thanks!

...
> +++ b/testcases/kernel/syscalls/mmap/mmap24.c
...
> +
> +		if ((unsigned long)addr + CHUNK_SZ > ADDR_LIMIT) {
> +			tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
%zu is wrong on 32 bit.

../../../../include/tst_test.h:75:55: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 6 has type ‘long unsigned int’ [-Wformat=]
   75 |                 tst_res_(__FILE__, __LINE__, (ttype), (arg_fmt), ##__VA_ARGS__);\
      |                                                       ^~~~~~~~~
mmap24.c:63:25: note: in expansion of macro ‘tst_res’
   63 |                         tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
      |                         ^~~~~~~

> +				addr, CHUNK_SZ);
> +			addrs[num_chunks++] = addr;
> +			cleanup();
> +			return;
> +		}
> +
> +		((char *)addr)[0] = 'a';
> +		((char *)addr)[CHUNK_SZ - 1] = 'z';
> +
> +		addrs[num_chunks++] = addr;
> +	}
> +
> +	if (!failed_with_enomem) {
> +		tst_res(TFAIL, "32-bit address space was not exhausted");
> +	} else if (!num_chunks) {
> +		tst_res(TFAIL, "failed to map any chunk with MAP_32BIT");
> +	} else {
> +		tst_res(TPASS,
> +			"Mapped %zu MB across %zu chunks within 2GB before ENOMEM",
And here as well.
> +			(num_chunks * CHUNK_SZ) / TST_MB, num_chunks);
> +	}
> +
> +	cleanup();
> +}
> +
> +static struct tst_test test = {
> +	.cleanup = cleanup,
> +	.test_all = run,
> +	.supported_archs = (const char *const []){
> +		"x86_64",
> +		NULL
> +	},
> +};


BTW I was wondering if I can get this failing when running on VM with really
small RAM, but even with 249 MB I get get mapped 928 MB (or 960 MB when I run
with -i):

mmap24.c:81: TPASS: Mapped 928 MB across 29 chunks within 2GB before ENOMEM

What am I missing?

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

Kind regards,
Petr

Before merge please:

diff --git testcases/kernel/syscalls/mmap/mmap24.c testcases/kernel/syscalls/mmap/mmap24.c
index 50de620f42..94d092b809 100644
--- testcases/kernel/syscalls/mmap/mmap24.c
+++ testcases/kernel/syscalls/mmap/mmap24.c
@@ -60,7 +60,7 @@ static void run(void)
 		}
 
 		if ((unsigned long)addr + CHUNK_SZ > ADDR_LIMIT) {
-			tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
+			tst_res(TFAIL, "mapping at %p + %lu exceeds 2GB limit",
 				addr, CHUNK_SZ);
 			addrs[num_chunks++] = addr;
 			cleanup();
@@ -79,7 +79,7 @@ static void run(void)
 		tst_res(TFAIL, "failed to map any chunk with MAP_32BIT");
 	} else {
 		tst_res(TPASS,
-			"Mapped %zu MB across %zu chunks within 2GB before ENOMEM",
+			"Mapped %lu MB across %zu chunks within 2GB before ENOMEM",
 			(num_chunks * CHUNK_SZ) / TST_MB, num_chunks);
 	}
 

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

Re: [LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Andrea Cervesato via ltp]

> Hi Andrea,
> 
> > Add a test verifying that mmap() with the MAP_32BIT flag restricts
> > mappings to the first 2GB of address space and fails with ENOMEM
> > when the 32-bit address space is exhausted without falling back to
> > higher addresses.
> 
> Thanks!
> 
> ...
> > +++ b/testcases/kernel/syscalls/mmap/mmap24.c
> ...
> > +
> > +		if ((unsigned long)addr + CHUNK_SZ > ADDR_LIMIT) {
> > +			tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
> %zu is wrong on 32 bit.
> 
> ../../../../include/tst_test.h:75:55: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 6 has type ‘long unsigned int’ [-Wformat=]
>    75 |                 tst_res_(__FILE__, __LINE__, (ttype), (arg_fmt), ##__VA_ARGS__);\
>       |                                                       ^~~~~~~~~
> mmap24.c:63:25: note: in expansion of macro ‘tst_res’
>    63 |                         tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
>       |                         ^~~~~~~

+1

> BTW I was wondering if I can get this failing when running on VM with really
> small RAM, but even with 249 MB I get get mapped 928 MB (or 960 MB when I run
> with -i):
> 
> mmap24.c:81: TPASS: Mapped 928 MB across 29 chunks within 2GB before ENOMEM
> 
> What am I missing?

Thanks for checking, I didn't verify 32-bits indeed..

I found the reason and it's really tricky. In arch/x86/kernel/sys_x86_64.c,
MAP_32BIT forces the mapping range to:

	begin = 0x40000000 (1 GB)
	end = 0x80000000 (2 GB)

Which is 1GB max.

And probably the reason why you can "map" 928 MB in a short memory system
is becasuee you are actually seeing virtual memory allocation. The test
is touching just 2 pages instead of all:

	((char *)addr)[0] = 'a';
	((char *)addr)[CHUNK_SZ - 1] = 'z';

can you try to apply a memset() for the whole allocation and see what
happens? The only problem if I use this method, tho, is that memory might
be swapped out.

I will send a new version with PROT_NONE that is allocating virtual
pages and changing a bit the logic of the final check.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

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

Re: [LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Petr Vorel]

Hi Andrea,

...
> > BTW I was wondering if I can get this failing when running on VM with really
> > small RAM, but even with 249 MB I get get mapped 928 MB (or 960 MB when I run
> > with -i):

> > mmap24.c:81: TPASS: Mapped 928 MB across 29 chunks within 2GB before ENOMEM

> > What am I missing?

> Thanks for checking, I didn't verify 32-bits indeed..

> I found the reason and it's really tricky. In arch/x86/kernel/sys_x86_64.c,
> MAP_32BIT forces the mapping range to:

> 	begin = 0x40000000 (1 GB)
> 	end = 0x80000000 (2 GB)

+1. That might explain the different value on mmap23.c as well.

> Which is 1GB max.

> And probably the reason why you can "map" 928 MB in a short memory system
> is becasuee you are actually seeing virtual memory allocation. The test
> is touching just 2 pages instead of all:

> 	((char *)addr)[0] = 'a';
> 	((char *)addr)[CHUNK_SZ - 1] = 'z';

> can you try to apply a memset() for the whole allocation and see what
> happens? The only problem if I use this method, tho, is that memory might
> be swapped out.

If you mean something like code below, the result is the same (+ of course big
slowdown).

+++ testcases/kernel/syscalls/mmap/mmap24.c
@@ -67,8 +67,9 @@ static void run(void)
                        return;
                }

-               ((char *)addr)[0] = 'a';
-               ((char *)addr)[CHUNK_SZ - 1] = 'z';
+               for (size_t j = 0; j < CHUNK_SZ; j++) {
+                       ((char *)addr)[j] = 'a';
+               }

                addrs[num_chunks++] = addr;
        }

> I will send a new version with PROT_NONE that is allocating virtual
> pages and changing a bit the logic of the final check.

+1

Kind regards,
Petr

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

[LTP] [PATCH v3 1/3] lapi/mmap: add MAP_32BIT fallback

[Andrea Cervesato]

From: Andrea Cervesato <andrea.cervesato@suse.com>

Reviewed-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
---
 include/lapi/mmap.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/lapi/mmap.h b/include/lapi/mmap.h
index 3908310f4..f20eb3bd5 100644
--- a/include/lapi/mmap.h
+++ b/include/lapi/mmap.h
@@ -91,6 +91,10 @@
 # define MAP_DROPPABLE 0x08
 #endif
 
+#ifndef MAP_32BIT
+# define MAP_32BIT 0x40
+#endif
+
 #ifndef MREMAP_DONTUNMAP
 # define MREMAP_DONTUNMAP 4
 #endif

-- 
2.51.0


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

Re: [LTP] lapi/mmap: add MAP_32BIT fallback

[linuxtestproject.agent]

Hi Andrea,

On Fri Sep 11 17:29:53 2026 +0200, Andrea Cervesato wrote:
> lapi/mmap: add MAP_32BIT fallback

Verdict - Reviewed

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

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