Bug 1270205

Summary: ltp/hugemmap02: symbol , version GLIBC_2.2 not defined in file libc.so.6 with link time reference
Product: Red Hat Enterprise Linux 7 Reporter: Li Wang <liwan>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: ashankar, fweimer, jstancek, mnewsome, pfrankli
Target Milestone: rc   
Target Release: ---   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-09 17:22:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Li Wang 2015-10-09 09:30:23 UTC
Description of problem:

# cat /proc/meminfo |grep Huge
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       1024 kB

# ./hugemmap02 
hugemmap02    0  TINFO  :  set nr_hugepages to 128
hugemmap02    1  TPASS  :  huge mmap succeeded (64-bit)
./hugemmap02: relocation error: ./hugemmap02: symbol , version GLIBC_2.2 not defined in file libc.so.6 with link time reference

# cat /proc/meminfo |grep Huge
AnonHugePages:         0 kB
HugePages_Total:     128
HugePages_Free:      128
HugePages_Rsvd:        2
HugePages_Surp:        0
Hugepagesize:       1024 kB


Version-Release number of selected component (if applicable):
# uname -r
3.10.0-229.el7.s390x

# rpm -q glibc
glibc-2.17-78.el7.s390x


How reproducible:
100%

Steps to Reproduce:
ltp upstream reproducer:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/hugetlb/hugemmap/hugemmap02.c


Actual results:
job link: https://beaker.engineering.redhat.com/recipes/2257010

Comment 2 Li Wang 2015-10-09 13:38:16 UTC
# cat reproducer.c 

#include <sys/types.h>
#include <sys/mman.h>
#include <errno.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define LOW_ADDR       (void *)(0x80000000)

static char TEMPFILE[4096];

static unsigned long *addr, *addr1, *addr2;
static int nfildes;

void main(int ac, char **av)
{
	long page_sz, map_sz;

	page_sz = getpagesize();
	map_sz = 1024 * 1024 * 2;


	/* Creat a file used for normal mapping */
	nfildes = open("/dev/zero", O_RDONLY, 0666);

	addr = mmap(0, 256 * 1024 * 1024, PROT_READ, MAP_SHARED, nfildes, 0);

	/* mmap using normal pages and a low memory address */
	addr1 = mmap(LOW_ADDR, page_sz, PROT_READ,
			MAP_SHARED | MAP_FIXED, nfildes, 0);

	munmap(addr, 256 * 1024 * 1024);
	close(nfildes);
}

# gcc reproducer.c 

# ./a.out 
Illegal instruction

Comment 3 Li Wang 2015-10-09 13:40:58 UTC
(In reply to Li Wang from comment #2)
> # cat reproducer.c 
> 
> #include <sys/types.h>
> #include <sys/mman.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> 
> #define LOW_ADDR       (void *)(0x80000000)

but if define the LOW_ADDR as '(void *)(0x90000000)', it could be PASS.

Comment 4 Carlos O'Donell 2015-10-09 17:22:37 UTC
Mapping /dev/zero at 0x80000000 will overwite the loaded application code (also mapped at 0x80000000 on s390x) with zeros. The execution of intstruction 0x0 will result in a SIGILL. Your program is working exactly as expected.

Program mappings and virtual address layout is extremely machine specific. You need to have some kind of exclusion list per machine to make this work on all machines e.g. a known good address where the huge mapping can be attempted.

This is exactly the same issue reported for exactly the same LTP test case 4 years ago. Please review the LTP waiver process or fix the upsteram LTP test case to scan the programs own mappings to find an empty region to use.

Marked CLOSED/DUPLICATE of bug 695703.

*** This bug has been marked as a duplicate of bug 695703 ***

Comment 5 Carlos O'Donell 2015-10-09 17:29:35 UTC
Notes:

The original failure listed was this:
~~~
# ./hugemmap02 
hugemmap02    0  TINFO  :  set nr_hugepages to 128
hugemmap02    1  TPASS  :  huge mmap succeeded (64-bit)
./hugemmap02: relocation error: ./hugemmap02: symbol , version GLIBC_2.2 not defined in file libc.so.6 with link time reference
~~~
is likely caused by mapping in zero where libc.so.6 was loaded and resulting in the dynamic loader finding no information about versions for the library. However, as noted, without an exclusion list for mappings, or active detection of a range for huge mappings, this test is flawed.