Date: Thu, 10 May 2001 00:40:28 -0700 From: Dima Dorfman <dima@unixfreak.org> To: hackers@freebsd.org Cc: phk@freebsd.org Subject: Who's cleaning up after disk_clone? Message-ID: <20010510074028.847EE3E28@bazooka.unixfreak.org>
next in thread | raw e-mail | index | archive | help
disk_clone is set as the dev_clone handler by the disk minilayer to create /dev/disk0sXY devices; however, as far as I can tell, those devices are never destroyed. For example (/dev is devfs here): dima@spike# mdconfig -a -t swap -s 32m md0 dima@spike# disklabel -r -w md0 auto dima@spike# ll /dev/md* crw-r----- 1 root operator 95, 0x00010002 May 10 00:12 /dev/md0 crw-r----- 1 root operator 95, 2 May 10 00:30 /dev/md0c crw------- 1 root wheel 95, 0xffff00ff May 10 00:12 /dev/mdctl dima@spike# mdconfig -du0 dima@spike# ll /dev/md* crw-r----- 1 root operator 95, 2 May 10 00:30 /dev/md0c crw------- 1 root wheel 95, 0xffff00ff May 10 00:12 /dev/mdctl Why is md0c still there? It was created as part of the disklabel operation. Furthermore, dima@spike# kldunload md dima@spike# ls /dev/md0c will cause a page fault in kernel mode in this situation. I can't get a crash dump, but vn_isdisk() was called from vn_stat() which was called from stat() (ls called this), and I'm guessing it crashed because there is a stale (now unloaded) cdevsw associated with /dev/md0c. So, my questions are: - is this a bug? At least the page fault is; and - what should be destroying /dev/md0c? Thanks for any insight, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010510074028.847EE3E28>