Date: Thu, 29 Nov 2012 00:21:30 +0100 From: Andre Oppermann <andre@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Alan Cox <alc@rice.edu> Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <50B69C7A.4010904@freebsd.org> In-Reply-To: <20121129100035.P1734@besplex.bde.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50B64BE8.3040708@rice.edu> <50B68F97.3010206@freebsd.org> <20121129100035.P1734@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B69C7A.4010904>