Date: Mon, 15 May 2000 13:06:14 +0100 From: Peter Edwards <peter.edwards@openet-telecom.com> To: Nick Hibma <n_hibma@calcaphon.com> Cc: phk@freebsd.org, FreeBSD CURRENT Mailing List <current@freebsd.org>, wc.bulte@chello.nl, Maxim Sobolev <sobomax@altavista.net> Subject: Re: vn.ko load/unload/mount = panic Message-ID: <391FE836.7DB49846@openet-telecom.com> References: <Pine.BSF.4.20.0005141328380.78621-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Nick Hibma wrote: > > Correct me if I am wrong, but I don't think you actually have to > disassociate any dev_t's from the driver (by clearing the si_drv[12] > fields) because we call destroy_dev and cdevsw_remove, so any later uses > of dev_t's get an error because the device has gone away. > > Apart from that I don't think we the calls to cdevsw_add/_destroy in the > first place, because we create the cdevsw on demand (with make_dev). > > Poul, is this correct? > > nick Hi, For the specific case of vn, there is a one-to-many correspondance between vn instances and dev_ts. The make_dev()/destroy_dev() pairs only bracket one of the dev_ts. Opens on the same instances of the vn through different dev_t's just assign the former's softc to the latter's si_drv1 field. There is no corresponding "make_dev()" or "destroy_dev()" call for such dev_t in the vn driver, so the si_drv1 fields dangle after the driver is unloaded The cdevsw_remove only stops access to the offending dev_t's until the driver is loaded again. After that, the old dev_ts' si_drv1 fields are still dangling, and the vn driver ends up with a pointer to a free()d vn softc, and bites the dust. After reading the rest of the discussion on this thread, and moving out of my depth a little, I assume vn should probably be using disk_create()/disk_destroy(), and attaching its softc to the disk object rather than the device object. (However, I suppose given the special nature of vn, there might be reasons for not using this interface). I'll gladly "disk"ify vn as a mini- junior-kernel-hacker task if someone indicates that it is needed, and if no one more qualified wants to do it. -- Peter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?391FE836.7DB49846>