Received:  by oss.sgi.com id <S42305AbQFUQzQ>;
	Wed, 21 Jun 2000 09:55:16 -0700
Received: from dialup341.canberra.net.au ([203.33.188.213]:62726 "HELO halfway")
	by oss.sgi.com with SMTP id <S42245AbQFUQy5>;
	Wed, 21 Jun 2000 09:54:57 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway (Postfix) with ESMTP
	id 4B30A8154; Wed, 21 Jun 2000 16:56:44 +1000 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     Keith Owens <kaos@ocs.com.au>
Cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: modular net drivers 
In-reply-to: Your message of "Wed, 21 Jun 2000 07:49:40 +1000."
             <4450.961537780@ocs3.ocs-net> 
Date:   Wed, 21 Jun 2000 16:56:44 +1000
Message-Id: <20000621065644.4B30A8154@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <4450.961537780@ocs3.ocs-net> you write:
> On Tue, 20 Jun 2000 17:01:56 +1000, 
> Rusty Russell <rusty@linuxcare.com.au> 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
`cleanup_finish(THIS_MODULE);'.

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,
Rusty.
--
Hacking time.