public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Thomas Koeller <thomas@koeller.dyndns.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: module use count & unloading
Date: Thu, 18 Dec 2003 14:22:33 -0800	[thread overview]
Message-ID: <20031218222233.GA3614@kroah.com> (raw)
In-Reply-To: <200312182303.05024.thomas@koeller.dyndns.org>

On Thu, Dec 18, 2003 at 11:03:04PM +0100, Thomas Koeller wrote:
> On Thursday 18 December 2003 17:37, Greg KH wrote:
> >
> > It wasn't safe to do that in 2.4 either.  That would easily unload your
> > USB controller drivers, USB keyboard and USB mouse drivers, as they all
> > do not increment their in-use count.
> 
> Thanks for your reply. I am, however, somewhat confused now. If the
> in-use count cannot be trusted, then unloading a module is a fundamentally
> unsafe operation, and a tool like 'rmmod' should not exist at all.

I agree, and so do any other kernel developers who have tried to handle
module cleanup properly :)

Some modules can't mark themselves as "busy" as there really isn't such
a operation for them (like the keyboard driver, when is it busy?  When
you are typing?)  So they allow themselves to be unloaded at any time if
you want to.

I don't think any distros have the 'rmmod cleanup' cron entry in them
anymore for this very reason.  I think that happened around the time 2.2
came out, but it might have been later...

> I also
> remember that in 2.4 periodic unloading of all unused autoloaded modules
> by a cron job used to work just fine. And finally, if module unloading is
> inherently unsafe, what is the significance of all this stuff about
> forced module unloading and its dangers?

module unload is there to help kernel developers.  Yes it does seem to
work for 99% of the time for everyone, but there's some fun races in
places that are almost impossible to fix properly.  See the various
threads in the lkml archives for more details on this (including Rusty's
proposed fix that we just never unload modules at all, but just mark the
memory as "used" and then load the next version in a different place.)

> I assumed this was a bug at first and reported it as one, because I could
> not make much sense of it. Now that I've been told that this kind of
> behavior is actually intended, I still cannot...

module unloading is tricky.  In short, if you can ever help it, don't.
It's there as a convience, and that's about it.  There's now a config
option that you have to explictly enable in order to get that "feature",
CONFIG_MODULE_UNLOAD.

Hope this helps clear things up.

greg k-h

      reply	other threads:[~2003-12-18 22:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-18 15:03 module use count & unloading Thomas Koeller
2003-12-18 16:37 ` Greg KH
2003-12-18 22:03   ` Thomas Koeller
2003-12-18 22:22     ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031218222233.GA3614@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@koeller.dyndns.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox