From owner-freebsd-hackers  Wed Apr 30 00:08:13 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA10803
          for hackers-outgoing; Wed, 30 Apr 1997 00:08:13 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10789
          for <hackers@FreeBSD.org>; Wed, 30 Apr 1997 00:08:10 -0700 (PDT)
Message-Id: <199704300708.AAA10789@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA246964031; Wed, 30 Apr 1997 17:07:11 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...)
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Wed, 30 Apr 1997 17:07:10 +1000 (EST)
Cc: bde@zeta.org.au, hackers@FreeBSD.org
In-Reply-To: <199704300332.NAA25320@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 30, 97 01:02:33 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

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.