linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* preventing module unload when entering open()?
@ 2003-07-01 14:25 Tuukka Toivonen
  0 siblings, 0 replies; only message in thread
From: Tuukka Toivonen @ 2003-07-01 14:25 UTC (permalink / raw)
  To: linux-kernel

At which times a kernel module can be unloaded if the use count is zero?

Let's say I have a device driver with my_open() function call. Initially,
device is not open, module use count is zero, and the module can be
unloaded. Then user opens the device with open() syscall.

Just after the open() syscall, but before the first line of my_open()
function has been executed, can the module be unloaded?

Linux Device Drivers by Alessandro Rubini, 2nd ed, ch. 3, hints in a source
code comment that MOD_INC_USE_COUNT must be done before the my_open() call
might sleep, implying that when kernel executes the my_open() function, it
will not unload the module even if use count is zero. However, I really
doubt if this is still true especially with SMP.

I'm interested in 2.2 and 2.4 kernels, with or without SMP.

Also note that I can't use the owner=THIS_MODULE thing, because I want to
support older V4L interface which doesn't have it.

I tested 2.2 and 2.4 inserting a long 10 sec sleep in the beginning of
my_open() before doing MOD_INC_USE_COUNT and when it slept tried to rmmod
the module. As expected, 2.2 crashed, for 2.4 rmmod hanged indefinitely and
/proc/modules shows "quickcam 1 (deleted)". So neither works properly if
MOD_INC_USE_COUNT is done _after_ sleeping, but it's difficult to test what
happens _before_ sleeping.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-07-01 14:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-01 14:25 preventing module unload when entering open()? Tuukka Toivonen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).