Date: Tue, 05 Dec 2000 19:02:00 +0000 From: Brian Somers <brian@Awfulhak.org> To: Julian Elischer <julian@elischer.org> Cc: Brian Somers <brian@Awfulhak.org>, smp@FreeBSD.org, archie@FreeBSD.org, brian@Awfulhak.org Subject: Re: Netgraph and SMP Message-ID: <200012051902.eB5J20Y38879@hak.lan.Awfulhak.org> In-Reply-To: Message from Julian Elischer <julian@elischer.org> of "Tue, 05 Dec 2000 07:03:02 PST." <3A2D03A6.B36803A2@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't think netgraph is the place to deal with this.
kldunload should be smart enough to do several things:
Look at the dependency graph that it maintains (does it?) and
decide if there are any dependent modules. If they are, refuse
the unload request.
Inside it's own lock (preventing any other dependent modules from
appearing), it asks the module if it's ok to unload.
This is obviously more tricky than it sounds. We've got to ensure
that if any character device entry points have been created
(make_dev() etc), we block the relevant entry points so that we can
ENODEV if the MOD_UNLOAD works.
Apart from the generic cdevsw entry points and module dependencies, I
think it's pretty much up to the module to ensure that things work -
unless someone can think of another way that an external source can
use the module (sysctls spring to mind).
> 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
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012051902.eB5J20Y38879>