From owner-freebsd-current Mon May 15 5:11: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from Mail.Openet-Telecom.COM (opentisdn.isdn.dublin.esat.net [193.120.50.79]) by hub.freebsd.org (Postfix) with ESMTP id 3E43D37B505; Mon, 15 May 2000 05:10:52 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from openet-telecom.com (rocklobster.openet-telecom.lan [10.0.0.40]) by Mail.Openet-Telecom.COM (8.9.3/8.9.3) with ESMTP id NAA72198; Mon, 15 May 2000 13:06:14 +0100 (IST) (envelope-from peter.edwards@openet-telecom.com) Message-ID: <391FE836.7DB49846@openet-telecom.com> Date: Mon, 15 May 2000 13:06:14 +0100 From: Peter Edwards Organization: Openet Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Hibma Cc: phk@freebsd.org, FreeBSD CURRENT Mailing List , wc.bulte@chello.nl, Maxim Sobolev Subject: Re: vn.ko load/unload/mount = panic References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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