Date: Mon, 30 Mar 2015 14:03:35 -0500 From: Alan Cox <alc@rice.edu> To: Don Lewis <truckman@FreeBSD.org>, kostikbel@gmail.com Cc: src-committers@FreeBSD.org, alc@FreeBSD.org, svn-src-all@FreeBSD.org, bdrewery@FreeBSD.org, portmgr@FreeBSD.org, svn-src-head@FreeBSD.org, clusteradm@FreeBSD.org Subject: Re: svn commit: r280327 - in head/sys: kern vm Message-ID: <55199E07.6010500@rice.edu> In-Reply-To: <201503301831.t2UIVClw095330@gw.catspoiler.org> References: <201503301831.t2UIVClw095330@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55199E07.6010500>