From owner-svn-src-head@FreeBSD.ORG Wed Nov 28 23:21:45 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 828EF9C2 for ; Wed, 28 Nov 2012 23:21:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DDB938FC12 for ; Wed, 28 Nov 2012 23:21:44 +0000 (UTC) Received: (qmail 46719 invoked from network); 29 Nov 2012 00:53:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2012 00:53:07 -0000 Message-ID: <50B69C7A.4010904@freebsd.org> Date: Thu, 29 Nov 2012 00:21:30 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bruce Evans Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50B64BE8.3040708@rice.edu> <50B68F97.3010206@freebsd.org> <20121129100035.P1734@besplex.bde.org> In-Reply-To: <20121129100035.P1734@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 28 Nov 2012 23:21:45 -0000 On 29.11.2012 00:14, Bruce Evans wrote: > On Wed, 28 Nov 2012, Andre Oppermann wrote: > >> On 28.11.2012 18:37, Alan Cox wrote: >>> I'm pretty sure that the "realmem" calculation is going to overflow on >>> i386/PAE, where the number of bytes of physical memory is greater than >>> the type long can represent. >> >> Right. long == int on i386/PAE, not LP64. Is uint64_t the correct type >> to use to catch that? > > No. 2**63-1 bytes of physical memory might be enough for anyone, but > more than that is is useful for virtual memory, and there is no need > to ensure that P128 will be broken when it exists. > > I would just use sizes in pages for everything so that 32-bit u_ints > are enough. Although this may break before P128 exists. Pages is not optimal as it would complicate the translations to the different mbuf sizes which are not necessarily integer multiple of pages. > Otherwise, uintmax_t should be used. Sloppy code can also depend on > uintmax_t being "infinitely" large, so that multiplications by small > scale factors don't overflow (use the more natural 'foo = bar * 3 / 4;' > instead of 'foo = bar / 4 * 3;', but this can still overflow if bar > is user input (say a tunable) that is not already limited enough. In the other patch I already sent to you I've used quad_t because we already have an existing TUNABLE_QUAD_FETCH macro for it. It also more natural for people to specify a memory related number in raw bytes rather than pages (which are 8k on IA64 IIRC). > vm_paddr_t could be used for physical memory sizes, but might be too > small or too large for virtual memory sizes, so using it would often > give the same bloat as using uintmax_t, and more complications than > using either u_int or uintmax_t for everything. -- Andre