mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: rusty@rustcorp.com.au
Cc: linux-kernel@vger.kernel.org, vandrove@vc.cvut.cz, zippel@linux-m68k.org
Subject: Re: Modules with list
Date: Tue, 26 Nov 2002 23:22:34 -0800	[thread overview]
Message-ID: <200211270722.XAA23313@adam.yggdrasil.com> (raw)

Rusty Russell wrote:
>In message <200211260649.WAA22216@adam.yggdrasil.com> you write:
>> >This would only happen if someone says "rmmod --wait".

>As I realized last night after I wrote this, there is a bug in
>module.c.  If O_NONBLOCK is specified, we shouldn't drop the module
>sempaphore at all, for exactly this reason.  A bug I introduced while
>"cleaning up" the "--wait" path.

>Sorry for the confusion.

	Then if you do "rmmod --wait" on some module that is in use,
every lsmod, insmod and rmmod will hang while attempting to acquire
module_mutex until the reference count on the module that you're
waiting to remove drops to zero, and there is no guarantee that that
will ever happen.  Some program might have to decide to close a file
descriptor or unmount a file system.  I think what you want is to
release the mutex before blocking and then reacquire it when you
continue.  Of course, you'll again have the scenario that I described.

	However, if you get rid of this idea of a blocking rmmod or
change it so that it does not make the module as "dead" if it is going
to block, then your idea of locking should work in the cases where
try_get_module() failure is handled by doing a request_module() and
retrying (because the insmod that request_module causes will acquire
module_mutex, so it will block until that module unload that was
causing the problem completes).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."


             reply	other threads:[~2002-11-27  7:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-27  7:22 Adam J. Richter [this message]
2002-11-27 23:15 ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2002-11-29  8:23 Adam J. Richter
2002-11-28  1:54 Adam J. Richter
2002-11-28  0:25 Adam J. Richter
2002-11-28 23:53 ` Rusty Russell
2002-11-27 19:04 Adam J. Richter
2002-11-27 18:19 Adam J. Richter
2002-11-27 22:42 ` Keith Owens
2002-11-27  7:01 Adam J. Richter
2002-11-26 16:18 Adam J. Richter
2002-11-27 17:05 ` Kai Germaschewski
2002-11-26  6:53 Adam J. Richter
2002-11-26  6:49 Adam J. Richter
2002-11-26 22:40 ` Rusty Russell
2002-11-26  4:06 Adam J. Richter
2002-11-26  5:04 ` Rusty Russell
2002-11-25 22:39 Adam J. Richter
2002-11-25 22:11 Adam J. Richter
2002-11-26  0:35 ` Rusty Russell
2002-11-26  7:57   ` Ingo Oeser

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=200211270722.XAA23313@adam.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=vandrove@vc.cvut.cz \
    --cc=zippel@linux-m68k.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

all inboxes | Powered by JetHome®