Date: Tue, 05 Dec 2000 07:03:02 -0800 From: Julian Elischer <julian@elischer.org> To: Brian Somers <brian@Awfulhak.org> Cc: smp@freebsd.org, archie@freebsd.org Subject: Re: Netgraph and SMP Message-ID: <3A2D03A6.B36803A2@elischer.org> References: <200012042307.eB4N7gD93751@hak.lan.Awfulhak.org>
index | next in thread | previous in thread | raw e-mail
Brian Somers wrote:
> > Er, no, you just have to acquire the exclusive lock in the MOD_UNLOAD
> > handler.
>
> Is it desirable to lock up running kldunload(8) ?
Personally I think it would be easier if the unload request were
simply refused for any module that is "in use".
Unfortunatly there is no real standard for this yet as far
as I can see. many modules just refuse to unload to solve
the problem, and some just unload blindly, hoping that
there are no users.
If I protect netgraph with a single user/modifier lock, as
Mike suggests (not a bad idea that) so that users
can hold off a modifier, I still face problems at the boundaries.
If the lock is in the Netgraph base code, which is a module,
I can have the problem where I have to ask the code that is being
removed, if it has any locks, yet I am in a race with another
process doing the same. If The other process is a bit ahead, then
just my attempt to gain the lock itself will result in a segfault
as I access the place where the lock USED to be.
We have that sort of problem all over the place.
For example:
We can have races between processes accessing /dev entries
racing with other processes removing the driver itself.
There is no lock on the devsw table that I am aware of (yet).
Particularly one that every device open needs to hold.
It seems to me that such a VERY FAST but specialised
user/modifier locking primitive would come in useful
all over the place. Unloading modules present a real
nightmare scenario, because you can't even trust a function
call into the module to tell you if it's available. That
function call or any locks that are in the module may
just 'go away' one instruction before you use them.
In a worst case scenario you should hold some special
lock every time you cross a boundary into code that is
supplied by a different module than one you already have
some hold over (whether that hold comes in the form of a
lock or a reference count, or an 'open count' doesn't
matter as long as it stops the module from being unloaded.
What happens if someone tries to do a 'mount -t dosfs'
just as someone else decides to unload the dosfs module?
We have no strategy that I am aware of to deal with this
sort of thing.
For now I have to make do with hoping that a device that
is turned off will not generate traffic, and that hopefully,
driver modules that have running instances will refuse to unload.
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A2D03A6.B36803A2>