Spuriously failing mprotect() on ppc64/ppc64le

[Jerry James]

Greetings,

I maintain the gcl package for Fedora.  Upstream recently announced support
for both ppc64 and ppc64le, so I attempted a build.  However, the build is
failing on an mprotect() call that looks, to me, like it ought to succeed.
This is not happening on any other architecture, so it is either something
in the ppc64-specific gcl code, or some quirk of Fedora ppc64 systems.
Here is an example build, with lots of debug prints added by yours truly:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2132156

In this case, it is the ppc64le build that failed, but it is the ppc64
build just as often.  We're in a race to see which one can die first.

Here's why I think the mprotect() should have succeeded.  Near the bottom
of build.log, you'll see a line that reads:

mprotect failure: 0x1470000 65536 7: Permission denied

... meaning that we called mprotect(0x1470000, 65536, PROT_READ |
PROT_WRITE | PROT_EXEC), it returned -1 to indicate failure, and errno ==
EACCES.  Above that is the contents of /proc/<pid>/smaps immediately after
the failing mprotect() call.  If you dig through that, you can find the
relevant memory region:

01210000-19b2f0000 rw-p 00000000 00:00 0
[heap]
Size:            6718336 kB
Rss:                5440 kB
Pss:                5440 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:      5440 kB
Referenced:         5440 kB
Anonymous:          5440 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Locked:                0 kB
VmFlags: rd wr mr mw me ac

As we can see from VmFlags, this memory region has the may-read, may-write,
and may-execute flags set, so there is no problem there.  The koji builders
have SELinux turned off (verified by running selinuxenabled at the top of
%build; see the message "SELinux is off. Smooth sailing ahead."), so thjis
is not an SELinux denial.

Can anybody think of any reason why that mprotect() call would have
failed?  Note that lots of similar mprotect() calls succeeded before this
one failed.

Thanks for any suggestions you can give.  Regards,
-- 
Jerry James
http://www.jamezone.org/