Subject: Re: Upgrade of `struct vnd_ioctl'
To: Bill Studenmund <>
From: Quentin Garnier <>
List: tech-kern
Date: 02/15/2007 14:45:53
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 14, 2007 at 12:39:58PM -0800, Bill Studenmund wrote:
> > Then, with that patch, VNDIOOCSET will not have the intended result...
> > And will write 4 extra bytes in memory or fault, depending on some
> > factors.
> >=20
> > What you need to do in the OVNDIOxxx cases is actually *convert* data
> > (which points to a struct oldvnd_ioctl) into a struct vnd_ioctl.
> Actually, this time I think we can get away with a little type casting=20
> magic. As I understand it, we are changing the length of the last field,=
> so we need only adjust how we handle it. Note: I'm also assuming we'll no=
> add more components in the future; if we were to, we should make the=20
> above-suggested change for conversion.
> 	vio->vnd_size =3D dbtob(((struct vnd_oioctl *)vnd)->sc_size);
> should work for now.

Okay, so first of all, I'm just back from California, I haven't slept
for 24 hours and spending 11 hours on a plane is not the best way to
get clear ideas.  So please assume good faith :-)

I *think* you're missing the fact that vio is the vnd_ioctl _or_
oldvnd_ioctl struct pointer.  vnd is the considered device's softc.

So whatever gross hack you use around the issue won't guarantee that
you don't end up writing 4 bytes after the end of the actually malloc'd

IOW, I'd rather see it done the clean way, which is actually not that
much a hassle :-)

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

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

Version: GnuPG v1.4.6 (NetBSD)