Blame SOURCES/libhugetlbfs-2.16-map_high_truncate.patch

f4a552
commit f008e0d18a4ba8ac26b67c5989efde3406bce535
f4a552
Author: Jan Stancek <jstancek@redhat.com>
f4a552
Date:   Fri Dec 5 13:57:04 2014 +0100
f4a552
f4a552
    lower mmap size of map_high_truncate_2 on 32bit s390
f4a552
    
f4a552
    The low and high limit passed to vm_unmapped_area() in
f4a552
    hugetlb_get_unmapped_area() is (TASK_UNMAPPED_BASE, TASK_SIZE).
f4a552
    
f4a552
    On 64-bit kernel this is defined as:
f4a552
      #define TASK_UNMAPPED_BASE (test_thread_flag(TIF_31BIT) ? \
f4a552
                                 (1UL << 30) : (1UL << 41))
f4a552
      #define TASK_SIZE_OF(tsk)  ((tsk)->mm->context.asce_limit)
f4a552
    
f4a552
    For 32-bit (-m31) process, this can be as small as
f4a552
    (0x40000000, 0x80000000), which is 0x40000000 bytes long area.
f4a552
    This testcase however is trying to allocate 0x60000000 and fails:
f4a552
      FAIL mmap() 1: Cannot allocate memory
f4a552
    
f4a552
    Lower mmap size to ~0x20000000, which is more likely to suit
f4a552
    address space constraints of 32-bit s390.
f4a552
    
f4a552
    Signed-off-by: Jan Stancek <jstancek@redhat.com>
f4a552
    Signed-off-by: Eric B Munson <emunson@mgebm.net>
f4a552
f4a552
diff --git a/tests/map_high_truncate_2.c b/tests/map_high_truncate_2.c
f4a552
index daabd00..2a2560b 100644
f4a552
--- a/tests/map_high_truncate_2.c
f4a552
+++ b/tests/map_high_truncate_2.c
f4a552
@@ -50,7 +50,11 @@
f4a552
  * 856fc29505556cf263f3dcda2533cf3766c14ab6.
f4a552
  */
f4a552
 #define MAP_LENGTH	(4 * hpage_size)
f4a552
-#define TRUNCATE_POINT	0x60000000UL
f4a552
+#if defined(__s390__) && __WORDSIZE == 32
f4a552
+#define TRUNCATE_POINT 0x20000000UL
f4a552
+#else
f4a552
+#define TRUNCATE_POINT 0x60000000UL
f4a552
+#endif
f4a552
 #define HIGH_ADDR	0xa0000000UL
f4a552
 
f4a552
 int main(int argc, char *argv[])