Date: Wed, 30 Apr 1997 17:07:10 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: bde@zeta.org.au, hackers@FreeBSD.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704300708.AAA10789@hub.freebsd.org> In-Reply-To: <199704300332.NAA25320@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 30, 97 01:02:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Michael Smith, sie said: > > Bruce Evans stands accused of saying: > > >Please keep me up to date on the results of your LKM-related tests. If > > >it turns out that there's a problem with unloading LKMs leaving occupied > > >but invalid devsw entries around we'd better fix it 8) > > > > Er, AFAIK unloading LKM drivers is broken in all cases. It certainly > > doesn't work for either of the officially supported LKM cdevs (joy > > and qcam). Unloading either of these and then attempting to opening > > the nonexistent device gives precisely the trap at _spec_open+0x6e that > > Simon reported (the devsw entry is not affected by unloading and points > > to garbage). Unloading followed by reloading obviously can't work, > > because the driver only initializes the devsw once. > > Um, the driver initialises the devsw on every load, does it not? eg: [...] > Still, I take your point about the cdevsw not being updated. I can't see > a clean way of doing this, either. > > Doug R., how do you approach this in your New Module Structure? (No, I > haven't had time to read it yet 8( 8( 8( ) Hmmm, IP Filter unloads and reloads easily enough. However, give some thought to a process which is in a kernel sleep state, inside the LKM and theLKM is removed, leaving the process still sleeping on a now invalid address.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704300708.AAA10789>