svn commit: r280327 - in head/sys: kern vm

[Don Lewis]

On 30 Mar, Konstantin Belousov wrote:
> On Sun, Mar 29, 2015 at 11:25:14PM -0700, Don Lewis wrote:
>> On amd64, with an amd64 jail, and kernel rev r280326, I observe the
>> following:
>> 	One gcc process calls mmap() with addr=0 and len=0x657a000, and
>>         the value 0x811400000 is returned.  Subsequent gcc processes
>>         call mmap() with addr=0x811400000 and len=0x657a000, getting
>>         0x811400000 in return.
>> 
>> With kernel rev r280327 I see:
>> 	One gcc process calls mmap() with addr=0 and len=0x657a000, and
>> 	the value 0x811400000 is returned.  Subsequent gcc processes
>> 	call mmap() with addr=0x811400000 and len=0x657a000, getting
>> 	0x8115f4000 in return.  What I later noticed is that the subsequent
>> 	calls are passing offset=0x1f4000.  Not so coincidentally,
>> 	0x811400000 + 0x1f4000 = 0x8115F4000.
>> 
>> My first attempt at a fix subtracted offset from address, but the mmap()
>> return value changed to 0x8113f4000 instead of the 0x811400000 I was
>> expecting.  It looked to me like the code must be doing superpage
>> alignment on the start of the file and then adding the offset to get the
>> start of the mapped region.
> So the real fix is to make gcc pass MAP_FIXED.

This PR <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940> explains
why MAP_FIXED can't be used.  Basically MAP_FIXED will silently clobber
any other mappings in that range, introducing other bugs.  MAP_FIXED |
MAP_EXCL would work, but we didn't get that until FreeBSD 10.

I think if the compiler specified the same offset to both mmap() calls,
it might work properly.

But that leaves the problem of actually fixing the compiler since it is
a binary that is part of some number of supported releases.  The usual
practice for port building is to populate the jails with releases.  It
is possible to set up jails that build from source, but that's not
commonly done and is broken in the case of 8.4 without extreme hackery.

The ports versions of gcc might also be affected, but that's less of
an issue.  It just requires patching those ports.

There is also the issue of customers who have a policy of only running
official release code.  When 11.0-RELEASE comes around, is is going to
have a release note that says that the compiler in a 9.3-RELEASE jail
doesn't work as well on an 11.0-RELEASE host vs. a 10.x-RELEASE host?

Also, is there any other code out in the wild that assumes the old
way that mmap() handled hints and will break when I runs on FreeBSD 11,
either in an older jail or on bare metal?

>> 
>> This somewhat hacking patch disables this alignment if a non-zero
>> address is passed as a hint, and allows the code to make the start of
>> the mapped region match the hint.  With this patch, I've been able to
>> build openjdk7 in a FreeBSD 9.3 amd64 jail.
>> 
> This is for precompiled headers, right ?  Could port disable pch ?

Correct.  I'm guessing that it is likely that the port could be tweaked
to disable pch.   I only build about 1100-1200 ports and found one that
broke.  We would need to do an exp run to find out how many others there
are.  That would take care of the problems of building the ports, but
the other issues would still remain.