From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 10:36:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 135B116A41F; Wed, 12 Oct 2005 10:36:27 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC4B43D53; Wed, 12 Oct 2005 10:36:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E2AA.dip.t-dialin.net [84.163.226.170] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1EPdyC06sI-0003z2; Wed, 12 Oct 2005 12:36:24 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 12:36:50 +0200 User-Agent: KMail/1.8.2 References: <20051011213800.GA8839@xor.obsecurity.org> In-Reply-To: <20051011213800.GA8839@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3464263.jPie93MmLt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510121237.07383.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: sparc64@freebsd.org, des@freebsd.org, Kris Kennaway Subject: Re: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 10:36:27 -0000 --nextPart3464263.jPie93MmLt Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 October 2005 23:38, Kris Kennaway wrote: > A few weeks ago I reported that bufinit() on sparc64 machines with > > >12GB of RAM goes into an infinite loop because of a 32-bit integer > > counter overflowing. On 5.x it was possible to work around this with > the kern.maxbcache tunable, but this didn't work on 6.0 or above. > > It turns out the problem began here: > > ---- > Revision 1.67 / (download) - annotate - [select for diffs], Mon Nov 8 > 18:20:02 2004 UTC (11 months ago) by des Branch: MAIN > Changes since 1.66: +17 -17 lines > Diff to previous 1.66 (colored) > > #include instead of (the former > includes the latter, but also declares variables which are defined > in kern/subr_param.c). > > Change som VM parameters from quad_t to unsigned long. They refer to > quantities (size limits for text, heap and stack segments) which must > necessarily be smaller than the size of the address space, so long is > adequate on all platforms. > > MFC after: 1 week > ---- > > which contained: > > -int maxswzone; /* max swmeta KVA storage */ > -int maxbcache; /* max buffer cache KVA storage */ > +long maxswzone; /* max swmeta KVA storage */ > +long maxbcache; /* max buffer cache KVA storage */ > > However, des forgot to change the other definition of maxbcache in > : > > extern int maxbcache; /* Max KVA for buffer cache */ > > In fact, it's a good thing he didn't. On sparc64 if you make that > variable a long it causes 32-bit integer overflows elsewhere, which > lead to severe filesystem damage on systems with >12GB RAM. With the > above bug this is reduced to a hang at boot. Isn't it enough to introduce the maximum values below? I imagine that the= =20 ultimate goal is to get rid of the constrains, which will be easier if we=20 already have enough bits. > The hang is because maxbcache is not capped to a maximum value on > sparc64, and a loop termination condition never occurs because of a > 32-bit integer overflow. On amd64 it's capped to > > /* > * Ceiling on size of buffer cache (really only effects write queueing, > * the VM page cache is not effected), can be changed via > * the kern.maxbcache /boot/loader.conf variable. > */ > #ifndef VM_BCACHE_SIZE_MAX > #define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) > #endif > > so large-memory amd64 systems never see it. ia64 and ppc would also > hang at boot with >12GB, I think. > > On 5.x, the same hang exists, but you can work around it with the > tunable. This tunable was broken by the long/int mismatch on 6.0, so > sparc64 systems with >12GB were unusable. > > This patch reverts the above int->long change, and adds definitions > for VM_BCACHE_SIZE_MAX and VM_SWZONE_SIZE_MAX on sparc64 copied from > amd64. Actually, they should probably be added on other architectures > too (ia64, ppc). > > Can someone please review? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3464263.jPie93MmLt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTOdTXyyEoT62BG0RAhYIAJ9MlHeu+lXjwgrOw/ZQ/ecl90Lo+gCcDxLL 4BSiJP1pYKOfeRTr2Y8Voo0= =oq8D -----END PGP SIGNATURE----- --nextPart3464263.jPie93MmLt--