[kris@obsecurity.org: integer overflow in bufinit() on large-memory machines]

Kris Kennaway kris at obsecurity.org
Mon Sep 26 07:44:44 PDT 2005


Can someone please look at this so that large memory sparc machines
(>11GB) are usable on FreeBSD?  The best workaround for now is
probably to limit the size of kva on sparc64 - e.g. amd64 sizes things
very differently so that on a 24GB machine it avoids the overflow by a
factor of 5.

Kris

----- Forwarded message from Kris Kennaway <kris at obsecurity.org> -----

X-Original-To: kkenn at localhost
Delivered-To: kkenn at localhost.obsecurity.org
X-Original-To: kris at freebsd.org
Delivered-To: kris at freebsd.org
X-Original-To: current at FreeBSD.org
Delivered-To: freebsd-current at FreeBSD.ORG
Date: Tue, 20 Sep 2005 12:57:40 -0400
From: Kris Kennaway <kris at obsecurity.org>
To: current at FreeBSD.org
User-Agent: Mutt/1.4.2.1i
Cc: 
Subject: integer overflow in bufinit() on large-memory machines
X-BeenThere: freebsd-current at freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request at freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current at freebsd.org>
List-Help: <mailto:freebsd-current-request at freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request at freebsd.org?subject=subscribe>
Errors-To: owner-freebsd-current at freebsd.org
X-UIDL: ~kM!!<P"#!1&m!!)(o"!
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=0.96.0

I have a sparc64 machine with 10GB of RAM that is hanging at boot in
bufinit() (also seen on other sparc64 machines with more than this
amount of RAM).  Instrumenting the code shows that it's happening
here:

/*
 * To support extreme low-memory systems, make sure hidirtybuffers cannot
 * eat up all available buffer space.  This occurs when our minimum cannot
 * be met.  We try to size hidirtybuffers to 3/4 our buffer space assuming
 * BKVASIZE'd (8K) buffers.
 */
        while (hidirtybuffers * BKVASIZE > 3 * hibufspace / 4) {
                hidirtybuffers >>= 1;
        }
        lodirtybuffers = hidirtybuffers / 2;

because 3*hibufspace is overflowing the 32-bit int hibufspace (this
code was added a few years ago by dillon).

hidirtybuffers=18182 BKVASIZE=16384 hibufspace=1189625856

I tried making hibufspace into a long which allowed the system to
boot, but the system panicked shortly afterwards while I was doing a
cvs diff:

> panic: vm_fault: fault on nofault entry, addr: 1e5884000
> db> wh
> Tracing pid 42 tid 100037 td 0xfffff802b13c57c0
> panic() at panic+0x164
> vm_fault() at vm_fault+0x21c
> trap_pfault() at trap_pfault+0x1a8
> trap() at trap+0x28c
> -- fast data access mmu miss tar=0x1e5884000 %o7=0xc02b12d8 --
> bcopy() at bcopy+0x9c
> ffs_sync() at ffs_sync+0x344
> sync_fsync() at sync_fsync+0x134
> VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb4
> sync_vnode() at sync_vnode+0xfc
> sched_sync() at sched_sync+0x24c
> fork_exit() at fork_exit+0x94
> fork_trampoline() at fork_trampoline+0x8

and upon rebooting it seems that my disk has been destroyed:

Boot device: disk  File and args:

>> FreeBSD/sparc64 boot block
   Boot path:   /sbus at 3,0/SUNW,fas at 3,8800000/sd at 0,0:a
   Boot loader: /boot/loader
File /boot/loader not found
Program terminated
{0} ok

I guess something else is really unhappy with hibufspace being that
large (or maybe there is some other variable overflowing).

Can anyone think of a solution?

Kris



----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20050926/1cbfc4bb/attachment.bin


More information about the freebsd-sparc64 mailing list