Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!fstgds15.tu-graz.ac.at!fstgds01.tu-graz.ac.at!not-for-mail From: chmr@edvz.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.os.386bsd.bugs Subject: Re: ioctls and core dumps Date: 24 Jun 1993 18:43:34 +0200 Organization: Technical University of Graz, Austria Lines: 73 Message-ID: <20cljmINNa7a@fstgds01.tu-graz.ac.at> References: <1993Jun22.173715.6498@fac.com> NNTP-Posting-Host: fstgds01.tu-graz.ac.at X-Newsreader: TIN [version 1.1 PL7] In article <1993Jun22.173715.6498@fac.com> Brian Moore (mooreb@fac.com) wrote: > I've had a rather wierd problem with ioctls... Here's the situation. > I'm working on a device driver for the Mitsumi cd-rom drive. One of > the ioctls I was working on was DIOCGDINFO, which is supposed to > return a disklabel. My driver doesn't return anything for that ioctl > yet. It doesn't even reference the data pointer at all. I wrote up > a test program to try some of the ioctls I was working on. When I > tried the DIOCGDINFO, passing in 0 for the data, the program dumped > core in the exit processing. DIOCGDINFO is defined as _IOR(...), the kernel copies data back to the user program no matter what your driver does. If your driver does not touch the data pointer, the kernel passes back uninitialized data... > Thereafter, the program would dump core > at the very beginning of the program no matter what ioctl I tried. > Even if I rebooted, the program would dump core right at the start. > A copy of the program made after it core dumped the first time would > also core dump. But a copy made before the first core dump would work > fine. The working and non-working copies compared as equal, so the > binary wasn't being changed in the filesystem. The bug is in locore.s, specifically copyout. You should use the version of Wolfgang Solfrank that he posted a while ago. I also posted a working version, but mine is slower. What happens is that the text area of your program is mapped at address 0 when it is executed, with read-only permissions. During ioctl, the kernel uses copyout to write the (supposed-to-be) disklabel into your program's adress space, address 0. This copyout does not check for the read-only status of this memory area, and happily overwrites your program text. When your program terminates, the VM system sees that part of your address space was written to, and writes the changes back to the executable file. (It does not check file permissions here, since you would not have been able to write to the page if it was not read-write, and it could not have been read-write if you didn't have the appropriate permissions -- or so it thinks). One interesting thing is that it also writes changes back to a READ-ONLY FILESYSTEM ! Anyway, your program is destroyed and you have to rebuild it (or use an old copy). > I fixed the dumps by > passing in a struct disklabel in the DIOCGDINFO ioctl. This makes it > look like the ioctl processing in the c library or kernel are doing > more than passing the data pointer on. I certainly expect the kernel > to do some checking, but I don't see why the program should continue > to dump core. for ioctls defined as _IO, the kernel simply passes the pointer. for _IOW, it copies the data from user space to temporary kernel space and passes the driver the pointer to the temporary space. For _IOR, it creates temporary space and copies it back to user mode when the driver ioctl routine finishes. The driver only operates on a temporary copy of the data the user program passes to ioctl. > > The $42 question is... Why did the program continue to dump core? > The only thing I could think of is that perhaps the ioctl processing > in the c library or the kernel mucks with the data area (mprotect, > clears it, or something else), which would really be the start of the > program because of the 0. As such, it might cause problems for future > runs of that program if it is kept in swap or cache or whatever. But > why would the program continue to core dump across reboots? The VM system pages the changes back to the executable file. Because the text area is mapped read-only, it does not really care what the VM system does with changes, since there are not supposed to be any. If you change the protections with mprotect, the VM system does the right thing. Hope that clears it up a bit, Christoph