From owner-svn-src-head@FreeBSD.ORG Thu Mar 26 22:29:10 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08445106566C; Thu, 26 Mar 2009 22:29:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id AC5CB8FC08; Thu, 26 Mar 2009 22:29:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2QMT4TI056217; Thu, 26 Mar 2009 16:29:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CC01B0.10801@samsco.org> Date: Thu, 26 Mar 2009 16:29:04 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Doug Ambrisko References: <200903262209.n2QM9NdZ078655@ambrisko.com> In-Reply-To: <200903262209.n2QM9NdZ078655@ambrisko.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Doug Ambrisko , src-committers@FreeBSD.org, John Baldwin , Roman Divacky , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r190445 - in head/sys: amd64/linux32 compat/linprocfs compat/linux conf dev/ipmi modules/ipmi modules/linprocfs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:29:10 -0000 Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 26 March 2009 5:29:42 pm Doug Ambrisko wrote: > [snip] > | > Maybe you have another suggestion to fix this. The problem showed up > | > when doing a mmap of 0xcf79c000 into 0xffffffffcf79c000 also a mmap > | > of 0xf0000 ended up the same way. This caused it to fail. Note this > | > is only on amd64 with a Linux. It didn't happen with a FreeBSD i386 > | > version on amd64. Here is a sample test program: > | > | I'm sure this can be easily fixed in the Linux mmap() handlers instead. Do > | you know if your Linux binary is using mmap2() or the old mmap()? > > I think it uses linux_mmap then bouncing it to linux_mmap_common. > linux_mmap_common had it right but when it mmap picked it up then > it was wrong in my intrumentation. > > I'll flip the l_off_t type back and then instrument it more to find > out when things are going bad. I missed the other usage of l_off_t > so I agree this is a bad change. However, I wonder if the other > usage of l_off_t actually works right or there is a bug with that > as well? Well, ultimately remember that offsets can be negative, by definition. Scott