--EVcIhgQsEzAXu06J
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I've spent a bit of time over the weekend working with the code I got
from Infosys, and I'm now at a point where I can create and write to
Vinum volumes:

It's not exactly what you'd call stable.  The first sync() call panics
the system:

#2  0xc02fa13b in panic (fmt=3D0xc0520920 "malloc: out of space in kmem_map=
") at ../../../../kern/subr_prf.c:222
#3  0xc02e5311 in malloc (size=3D3735928559, ksp=3D0xc0674d00, flags=3D0) a=
t ../../../../kern/kern_malloc.c:294
#4  0xc019f466 in MMalloc (size=3D-559038737, file=3D0xc04f3e20 "../../../.=
./dev/vinum/vinumrequest.c", line=3D274)
    at ../../../../dev/vinum/vinummemory.c:113
#5  0xc01a10bf in vinumstart (bp=3D0xc0a7c0f0, reviveok=3D0) at ../../../..=
/dev/vinum/vinumrequest.c:274
#6  0xc01a0ecd in vinumstrategy (bp=3D0xc0a7c0f0) at ../../../../dev/vinum/=
vinumrequest.c:164
#7  0xc0324b0e in spec_strategy (v=3D0xcb225ad4) at ../../../../miscfs/spec=
fs/spec_vnops.c:592
#8  0xc02c7aeb in ufs_strategy (v=3D0xcb225ad4) at ../../../../ufs/ufs/ufs_=
vnops.c:1756
#9  0xc031f56b in VOP_STRATEGY (bp=3D0xc0a7c0f0) at ../../../../kern/vnode_=
if.c:102
#10 0xc0322dac in genfs_gop_write (vp=3D0xcb54e3c0, pgs=3D0xcb225b84, npage=
s=3D3, flags=3D17)
    at ../../../../miscfs/genfs/genfs_vnops.c:1471
#11 0xc032282f in genfs_putpages (v=3D0xcb225d20) at ../../../../miscfs/gen=
fs/genfs_vnops.c:1297
#12 0xc02c0807 in ffs_putpages (v=3D0xcb225d20) at ../../../../ufs/ffs/ffs_=
vnops.c:567
#13 0xc03201ad in VOP_PUTPAGES (vp=3D0xcb54e3c0, offlo=3D0, offhi=3D0, flag=
s=3D17) at ../../../../kern/vnode_if.c:1665
#14 0xc02c03d1 in ffs_full_fsync (v=3D0xcb225e58) at ../../../../ufs/ffs/ff=
s_vnops.c:357
#15 0xc02c00ec in ffs_fsync (v=3D0xcb225e58) at ../../../../ufs/ffs/ffs_vno=
ps.c:263
#16 0xc031f9f8 in VOP_FSYNC (vp=3D0xcb54e3c0, cred=3D0xc09c5f00, flags=3D0,=
 offlo=3D0, offhi=3D0, p=3D0xcb1ff9c0)
    at ../../../../kern/vnode_if.c:691
#17 0xc02be843 in ffs_sync (mp=3D0xc0b1d000, waitfor=3D3, cred=3D0xc09c5f00=
, p=3D0xcb1ff9c0)
    at ../../../../ufs/ffs/ffs_vfsops.c:1269
#18 0xc03252ec in sync_fsync (v=3D0xcb225f28) at ../../../../miscfs/syncfs/=
sync_vnops.c:160
#19 0xc031f9f8 in VOP_FSYNC (vp=3D0xcb53c350, cred=3D0xc09c5f00, flags=3D8,=
 offlo=3D0, offhi=3D0, p=3D0xcb1ff9c0)
    at ../../../../kern/vnode_if.c:691
#20 0xc0325059 in sched_sync (v=3D0xcb208300) at ../../../../miscfs/syncfs/=
sync_subr.c:188

Looking at the buffer header passed to Vinum, I see:

(gdb) p *bp
$1 =3D {
  b_hash =3D {
    le_next =3D 0xc0a7c690,=20
    le_prev =3D 0xc0a7cfe0
  },=20
  b_vnbufs =3D {
    le_next =3D 0xdeadbeef,=20
    le_prev =3D 0xdeadbeef
  },=20
  b_freelist =3D {
    tqe_next =3D 0xdeadbeef,=20
    tqe_prev =3D 0xdeadbeef
  },=20
  b_actq =3D {
    tqe_next =3D 0xdeadbeef,=20
    tqe_prev =3D 0xdeadbeef
  },=20
  b_proc =3D 0xdeadbeef,=20
  b_flags =3D 84,=20
  b_interlock =3D {
    lock_data =3D 0
  },=20
  b_error =3D -559038737,=20
  b_bufsize =3D -559038737,=20
  b_bcount =3D 8192,=20
  b_resid =3D 8192,=20
  b_dev =3D 6400,=20
  b_un =3D {
    b_addr =3D 0xc29ab000 "\037\213\b\bs\222=A3>"
  },=20
  b_saveaddr =3D 0xdeadbeef,=20
  b_lblkno =3D 0,=20
  b_blkno =3D 1920,=20
  b_rawblkno =3D -2401053088876216593,=20
  b_iodone =3D 0xc036cefc <uvm_aio_biodone1>,=20
  b_vp =3D 0xcb54e3c0,=20
  b_private =3D 0xc0a7ca50,=20
  b_dcookie =3D -2401053088876216593,=20
  b_dep =3D {
    lh_first =3D 0x0
  }
}

In Vinum, I do:

#5  0xc01a10bf in vinumstart (bp=3D0xc0a7c0f0, reviveok=3D0) at ../../../..=
/dev/vinum/vinumrequest.c:274
274                     bp->b_data =3D Malloc(bp->b_bufsize);

Given the uninitialized b_bufsize member, that causes a panic:

#2  0xc02fa13b in panic (fmt=3D0xc0520920 "malloc: out of space in kmem_map=
") at ../../../../kern/subr_prf.c:222

It's simple enough to "fix" this panic: use b_bcount instead of
b_bufsize.  But is that the correct fix?  Is it valid to have an
uninitialized b_bufsize?  If so, when, and what use is the field?

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers

--EVcIhgQsEzAXu06J
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE+pKDPIubykFB6QiMRAlmJAKCvkzknfJ5m6NwfK8SJ3qti3MUJvQCgp3A2
Jzb352WOlrQ13eeL7oKUvU0=
=Z34f
-----END PGP SIGNATURE-----

--EVcIhgQsEzAXu06J--