Date: Thu, 22 Apr 2010 16:36:28 -0700 From: "Matthew Fleming" <matthew.fleming@isilon.com> To: "Garrett Cooper" <yanefbsd@gmail.com> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: RE: Error checking in ioctl(2)? Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E039E33A7@seaxch09.desktop.isilon.com> In-Reply-To: <w2v7d6fde3d1004221627jff97746bkcb8cd3ca5e5a7492@mail.gmail.com> References: <w2v7d6fde3d1004221627jff97746bkcb8cd3ca5e5a7492@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi hackers,
> I realize that this isn't 100% userland code, so the checks should
> be minimalized, but when looking at the ioctl(2) syscall code (at
> least I think it is... there's another dupe hanging around in
> sys/dev/hptmv/ioctl.c), I had some questions related to the error
> handling not being done in the code:
>=20
> if (size > 0) {
> if (com & IOC_VOID) {
> /* Integer argument. */
> arg =3D (intptr_t)uap->data;
> data =3D (void *)&arg;
> size =3D 0;
> } else
> data =3D malloc((u_long)size, M_IOCTLOPS,
> M_WAITOK); /* XXX: can fail -- do we care? */
malloc(9) with M_WAITOK cannot return NULL. So the rest of your XXX
comments are not at issue.
Also, free(9) is documented to do the right thing when asked to
free(NULL).
copyin/copyout are really just bcopy but unlike most kernel code they
are allowed to take a page fault. They deal with this by setting a
function pointer in PCB_ONFAULT, which is used in trap() to set a return
instruction pointer.
Cheers,
matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D5F9F6F655AD4C92E28B662F7F853E039E33A7>