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

[Alan Cox]

On 03/30/2015 13:31, Don Lewis wrote:
> 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.

This is precisely why config/host-solaris.c does a series of mincore()
calls.

> 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.
>
>