>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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/