Date: Wed, 13 May 98 08:37:17 EDT From: luoqi@watermarkgroup.com (Luoqi Chen) To: bde@FreeBSD.ORG, bde@zeta.org.au, 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: <9805131237.AA06678@watermarkgroup.com>
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. Never thought about this before. Thanks for pointing it out, now I see how evil it could be. ... > 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? I guess we could make SLICE code do that. But eventually we'd like to get rid of dev_t all together, we have to find another way to figure out if a disk partition is a swap partition. IMO, using disklabel is the correct way (being a 'b' partition doesn't prevent user from creating a fs in it, and being a non-'b' partition doesn't mean you can't use it as a swap). It's just bad luck we couldn't retrieve disklabel during a dump. I have a suggestion: since swap and dump code are the only consumers of d_psize(), can we change d_psize to return disklabel instead (similar to what DIOCGPART does)? This would also allow us to get rid of the DIOCGPART kludge (ioctl should only be called from userland). If you think this is doable, I can work out a patch for that. > > Bruce > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9805131237.AA06678>