[Top] [All Lists]

Re: modular net drivers

To: Keith Owens <kaos@xxxxxxxxxx>
Subject: Re: modular net drivers
From: Rusty Russell <rusty@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Jun 2000 16:56:44 +1000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: Your message of "Wed, 21 Jun 2000 07:49:40 +1000." <4450.961537780@ocs3.ocs-net>
Sender: owner-netdev@xxxxxxxxxxx
In message <4450.961537780@xxxxxxxxxxxx> you write:
> On Tue, 20 Jun 2000 17:01:56 +1000, 
> Rusty Russell <rusty@xxxxxxxxxxxxxxxx> wrote:
> >Races which can be largely solved at the moment by having the module
> >page removal code sync all bh's and softirqs after calling cleanup().
> >Hell, we could even poll all CPUs and check they're not executing in
> >the about-to-be-freed pages.  Speed is completely unimportant here.
> This race is not obvious but IMHO it exists.  The original theory was 

[ Entry into other points of module during module_cleanup() example
  snipped ]

Well, that race is obvious, IMHO.

module_cleanup should unregister everything first, before doing other
cleaning up (which might sleep).  I consider this fundamental, anyway;
there's no other sane mechanism (unless you really do want to turn us
into a microkernel).

> Checking in module_cleanup() to see if the use count has changed is not
> a solution.  module_cleanup() may already have destroyed structures
> that the open() code expects to use, either immediately or later.

Of course... but two-stage cleanup (as suggested by Alexey long ago)
will solve this, too.

If you have non-trivial requirements, you need to do some form of
reference counting anyway; cleanup() then just assures that the
reference count will never *rise*.  When it hits zero, you call

This would certainly solve *my* problems.

I can provide code if this is still not clear how this keeps the
penalty for being a module in the module, and does not pollute the
rest of the kernel.

Please consider,
Hacking time.

<Prev in Thread] Current Thread [Next in Thread>