Date: Wed, 15 Jul 1998 08:50:01 -0700 (PDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/7282: some old and rarely used drivers have apparently become broken Message-ID: <199807151550.IAA17973@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/7282; it has been noted by GNATS. From: woods@zeus.leitch.com (Greg A. Woods) To: Bruce Evans <bde@zeta.org.au> Cc: FreeBSD-gnats-submit@FreeBSD.ORG, erich@rrnet.com Subject: Re: kern/7282: some old and rarely used drivers have apparently become broken Date: Wed, 15 Jul 1998 11:41:59 -0400 (EDT) [ On Wed, July 15, 1998 at 09:57:27 (+1000), Bruce Evans wrote: ] > Subject: Re: kern/7282: some old and rarely used drivers have apparently become broken > > > It would seem as though all drivers were not converted to use > > the new driver ioctl() interface, i.e. the the one where driver > > ioctl() routines should not use copyin()/copyout() because this > > is done for them one level up. > > It's not new. It's (much?) older than Net/3, much older than any > FreeBSD driver. I guess I should have run "cvs annotate" on sys/kern/sys_generic.c once I'd found out that the ioctl() driver wrapper in there actually does the copyin() already. Then I would have noticed that the copyin() and copyout() calls in that wrapper have been there since the file was added to the FreeBSD repository. Yes, this same code is also in my archive of Net/2 (i.e. 4.3Tahoe). However given the way other Unix variants implement driver ioctl() routines, and according to the document written by Eric, and all of my past experience writing drivers for other Unix variants, I fully expected I would have to use copyin()/copyout() in the driver ioctl() routine. Now that I think I understand how BSD truely implements the ioctl() system call I don't see how use of copyin()/copyout() in a driver ioctl() routine could ever work. The other clue that on hindsight is quite obvious is that the macros used to "create" ioctl command descriptors know the size of the data structure to be copied. (I've been rather annoyed at this change in the kernel/driver interface for some time though because it totally prevents any chance of backwards compatability with userland should one need to add a new field to a data structure passed through ioctl(). Perhaps my annoyance clouded my ability to see this as a clue to the problem I was seeing.) > > Possibly even mention in copyin.9 et al that these routines > > should not be used in driver ioctl() routines. > > But they should be used if the data is larger than will fit in the > ioctl data. labpc uses them to copy rather small data that probably > should have been put in the ioctl data. If DSI_SOFT_MODEM is > configured, then sio uses copyin() to copy arbitrarly large data > (large enough to use all of kernel memory :-(). Given my experimentation, and subsequent code walkthrough to find out how the driver *_ioctl() routines get called, I can't see how any driver can ever successfully use copyin() or copyout() in the driver *_ioctl() routines themselves. Any time I tried, no matter how small or large the data segment being copied, all I ever got back from thouse routines was EFAULT. I.e. the labpc driver *must* be broken (though it may be lucky enough not to fail if the copyin()/copyout() calls it makes never cause a page fault in practice). -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807151550.IAA17973>