T.mprotect is a problem for ppc32 (binary) running in ppc64 system as it has to
be manually intervene the test by typing Ctrl-C.
We believe this is a testsuite bug, as it calls mprotect (addr, len, PROT_EXEC)
where (uintptr_t) (addr + len) < (uintptr_t) addr and expects -1/ENOMEM (which
it gets).
However, http://www.opengroup.org/onlinepubs/009695399/functions/mprotect.html
has:
When mprotect() fails for reasons other than [EINVAL], the protections on some
of the pages in the range [addr,addr+len) may have been changed.
...
[ENOMEM] Addresses in the range [addr,addr+len) are invalid for the address
space of a process, or specify one or more pages which are not mapped.
And for 32-bit processes on 64-bit arches (we believe all of x86_64, ppc64,
s390x at least behave this way) mprotect (0x40000000, 0xf0000000, PROT_EXEC)
indeed modifies some VMA protections, while e.g. on i686 32-bit kernel it
doesn't. There is
len = PAGE_ALIGN(len);
end = start + len;
if (end < start)
return -ENOMEM;
test in mm/mprotect.c, but as len, start and end are all 64-bit at this point in
64-bit kernels, this does nothing for 32-bit processes.
Not sure if we want to add if (start + PAGE_ALIGN (len) < start) return -ENOMEM;
tests in sys32_mprotect wrappers or not.
32bit lsb-runtime-test running on 64-bit kernel only.
==================
10|857 /tset/LSB.os/mprotect/mprotect_P/T.mprotect_P 08:19:37|TC Start,
scenario ref 863-0
15|857 3.6-lite 11|TCM Start
400|857 1 1 08:19:37|IC Start
...
400|857 8 1 08:19:51|IC Start
200|857 8 08:19:51|TP Start
220|857 8 7 21:45:44|NORESULT (auto-generated by TCC)
90|21:45:44|User Abort
--
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.