Date: Wed, 13 May 1998 21:13:44 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, luoqi@watermarkgroup.com Subject: Re: cvs commit: src/sys/i386/i386 autoconf.c src/sys/kern kern_shutdown.c Message-ID: <199805131113.VAA31165@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I know it is a kludge when I submit. But the specific ioctl (DIOCGPART) >is only intended to be called (if I understand correctly) from a kernel Tru. A kernel context with the device open. >context, so absence of a process context shouldn't really matter. As to It matters. E.g., if the device has never been opened, then the driver would have read the label from the disk. Even if the device is open and the label is in core, some layers of the driver may not know this and may sleep. The bug showed up for a sleep in interrupt context here: system idle (curproc == NULL) fdintr (handle floppy interrupt) panic for unmapped bp->b_data (stale vm objbuf bug) dumpsys wdioctl wdsleep (get exclusive access to wd controller) tsleep (need to wait, but would wait forever) trap to ddb for proc = curproc = NULL tsleep() has some kludges to allow it to sort of work if it is called in `cold' or panic contexts, but the KTRACE support at the beginning of it breaks these if the proc pointer is null. If we set curproc = proc0 in an attempt to avoid this, then wdsleep() might hang instead of panicing. Setting curproc = proc0 for sync() in panic doesn't really work either, but there's nothing better. OTOH, the dump routine is supposed to work in almost any context. >calling d_ioctl on non-open devices, I have to admit it's inapporiate. >But again for the DIOCGPART ioctl, it is no more evil than calling d_psize >or d_dump -- they all make the same assumption (i.e. slices are initialized). No, correct versions of d_psize() open and close the device if necessary (see dssize() or pre-slice versions of all the drivers that supported dumping (wd and sd). d_dump() only assumes that the slice table is valid if it is non-null. If dumping is enabled, then there must have been a previous call to d_psize() from setdumpdev(), and the slice table should be left around after the open/close in this. Also, in the usual case where the dump device is the same as a swap device, there are few problems because the swap device is held open. >The previous commit is necessary to enable dump for a SLICE kernel. An The SLICE kernel should follow the standard conventions and set dkpart(dev) = 1 for 'b' partitions. This convention is also used by config (`dumps on wd0' gives dumpdev = device for non-SLICED wd0b, and cpu_dumpconf() calls setdumpdev(dumpdev). What does the SLICE code do with raw dev numbers not created by it? >alternative would be to get rid of the bogus swap partition check. One >has to be extremely careful not to point dump dev to a fs partition after >this safty check is gone. I think things would be safe enough if the check is moved to user space. Make dumpon(1) enforce the 'b' partition and unless a new option is used to tell it that you really want the device that you specified. The kern.dumpdev sysctl is too hard to use directly, so there is probably no need to restrict it. >We will still have problem with d_dump and d_psize for device that has >never been opened (and thus slices not initialized) unless we switch to >a SLICE kernel. Or call dsinit() in an interrupt hook just as what the >slice device does. The only known problems with ordinary kernels here are that the dump configuration doesn't go away when the dumpdev goes away or changes. Perhaps the pointer to the slice table is set to non-NULL before the table is fully initialized, so a panic during initialization of the slice table for the dump device would cause problems, but there are many other pointer initializations with similar problems. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805131113.VAA31165>