integer overflow in bufinit() on large-memory machines

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Tue, 20 Sep 2005 12:57:40 -0400
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

Received on Tue Sep 20 2005 - 14:57:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC