From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 19:03:45 2015 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F573FDF; Mon, 30 Mar 2015 19:03:45 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 634C23BA; Mon, 30 Mar 2015 19:03:44 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id t2UJ1p7p029208; Mon, 30 Mar 2015 14:03:38 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1tf8ay8agy-1; Mon, 30 Mar 2015 14:03:36 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 2FEEE460197; Mon, 30 Mar 2015 14:03:36 -0500 (CDT) Message-ID: <55199E07.6010500@rice.edu> Date: Mon, 30 Mar 2015 14:03:35 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Don Lewis , kostikbel@gmail.com Subject: Re: svn commit: r280327 - in head/sys: kern vm References: <201503301831.t2UIVClw095330@gw.catspoiler.org> In-Reply-To: <201503301831.t2UIVClw095330@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503300176 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 19:03:45 -0000 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 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. > >