Re: vn.ko load/unload/mount = panic

[Peter Edwards]

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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message