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

[Li Wang]

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