Actually, there seems to be a way to list processes that claim a module/driver - however, I haven't seen it advertised (outside of Linux kernel documentation), so I'll jot down my notes here:
First of all, many thanks for @haggai_e 's answer; the pointer to the functions try_module_get and try_module_put as those responsible for managing the use count (refcount) was the key that allowed me to track down the procedure.
Looking further for this online, I somehow stumbled upon the post Linux-Kernel Archive: [PATCH 1/2] tracing: Reduce overhead of module tracepoints ; which finally pointed to a facility present in the kernel, known as (I guess) "tracing"; the documentation for this is in the directory Documentation/trace - Linux kernel source tree. In particular, two files explain the tracing facility, events.txt and ftrace.txt .
But, there is also a short "tracing mini-HOWTO" on a running Linux system in /sys/kernel/debug/tracing/README (see also I'm really really tired of people saying that there's no documentation… ); note that in the kernel source tree, this file is actually generated by the file kernel/trace/trace.c. I've tested this on Ubuntu natty. and note that since /sys is owned by root, you have to use sudo to read this file, as in sudo cat or
. and that goes for pretty much all other operations under /sys which will be described here.
First of all, here is a simple minimal module/driver code (which I put together from the referred resources), which simply creates a /proc/testmod-sample file node, which returns the string "This is testmod." when it is being read; this is testmod.c :
This module can be built with the following Makefile (just have it placed in the same directory as testmod.c. and then run make in that same directory):
When this module/driver is built, the output is a kernel object file, testmod.ko.
At this point, we can prepare the event tracing related to try_module_get and try_module_put ; those are in /sys/kernel/debug/tracing/events/module :
Note that on my system, tracing is by default enabled:
. however, the module tracing (specifically) is not:
Now, we should first make a filter, that will react on the module_get. module_put etc events, but only for the testmod module. To do that, we should first check the format of the event:
Here we can see that there is a field called name. which holds the driver name, which we can filter against. To create a filter, we simply echo the filter string into the corresponding file:
Here, first note that since we have to call sudo. we have to wrap the whole echo redirection as an argument command of a sudo -ed bash. Second, note that since we wrote to the "parent" module/filter. not the specific events (which would be module/module_put/filter etc), this filter will be applied to all events listed as "children" of module directory.
Finally, we enable tracing for module:
From this point on, we can read the trace log file; for me, reading the blocking, "piped" version
of the trace file worked - like this:
At this point, we will not see anything in the log - so it is time to load (and utilize, and remove) the driver (in a different terminal from where trace_pipe is being read):
If we go back to the terminal where trace_pipe is being read, we should see something like:
That is pretty much all we will obtain for our testmod driver - the refcount changes only when the driver is loaded ( insmod ) or unloaded ( rmmod ), not when we do a read through cat. So we can simply interrupt the read from trace_pipe with CTRL + C in that terminal; and to stop the tracing altogether:
Here, note that most examples refer to reading the file /sys/kernel/debug/tracing/trace instead of trace_pipe as here. However, one problem is that this file is not meant to be "piped" (so you shouldn't run a tail -f on this trace file); but instead you should re-read the trace after each operation. After the first insmod. we would obtain the same output from cat -ing both trace and trace_pipe ; however, after the rmmod. reading the trace file would give:
. that is: at this point, the insmod had already been exited for long, and so it doesn't exist anymore in the process list - and therefore cannot be found via the recorded process ID (PID) at the time - thus we get a blank <. > as process name. Therefore, it is better to log (via tee ) a running output from trace_pipe in this case. Also, note that in order to clear/reset/erase the trace file, one simply writes a 0 to it:
If this seems counterintuitive, note that trace is a special file, and will always report a file size of zero anyways:
. even if it is "full".
Finally, note that if we didn't implement a filter, we would have obtained a log of all module calls on the running system - which would log any call (also background) to grep and such, as those use the binfmt_misc module:
. which adds quite a bit of overhead (in both log data ammount, and processing time required to generate it).
While looking this up, I stumbled upon Debugging Linux Kernel by Ftrace PDF. which refers to a tool trace-cmd. which pretty much does the similar as above - but through an easier command line interface. There is also a "front-end reader" GUI for trace-cmd called KernelShark ; both of these are also in Debian/Ubuntu repositories via sudo apt-get install trace-cmd kernelshark. These tools could be an alternative to the procedure described above.
Finally, I'd just note that, while the above testmod example doesn't really show use in context of multiple claims, I have used the same tracing procedure to discover that an USB module I'm coding, was repeatedly claimed by pulseaudio as soon as the USB device was plugged in - so the procedure seems to work for such use cases.