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."
next 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®