8

I'm working with a large embedded software (ARM processor, embedded linux 2.6.31, busybox) involving both kernel and user space code. There's a kernel module normally loaded first, and daemon establishing netlink socket with the module.

The issue here is that after killing the daemon, I'm no longer able to unload the module from the memory:

% rmmod _module.ko
% rmmod: _module.ko: Resource temporarily unavailable

Analysis has shown that error (return value is -11, i.e. EAGAIN?) is returned by try_stop_module() invoked in syscall delete_module() definition in kernel/module.c. Function try_stop_module() in turn calls stop_machine() and this is where I've stuck, as

I'm not sure what's exactly happening there. I think the root cause is somewhere in the daemon that opens connections to the module and obviously something else and doesn't correctly close/clean-up on exit (apparently some references/locks are not released?)

Does anybody have any idea what else to look at and probe?

ymn
  • 2,175
  • 2
  • 21
  • 39
Mark
  • 6,052
  • 8
  • 61
  • 129

2 Answers2

2

Check whether all the interfaces related to your module is not 'up'.

if any of the interface which is related to your module is 'up',then rmmod will fail and returns with -11.

So before calling rmmod, check the active interfaces using 'netcfg' command. then using ifconfig,make your interface down as 'ifconfig <interface_name> down'

then try to run rmmod <module_name>. it will work!!

1.netcfg <lists out all interfaces>
2.ifconfig <interface_name> down
3.rmmod <module_name>
Nandan_G
  • 21
  • 2
1

First of all you should be a superuser to do this. Also you can use rmmod -f but this option can be extremely dangerous: it has no effect unless CONFIG_MODULE_FORCE_UNLOAD was set when the kernel was compiled. With this option, you can remove modules which are being used, or which are not designed to be removed, or have been marked as unsafe.

Also read man rmmod.

ymn
  • 2,175
  • 2
  • 21
  • 39
  • thanks for comments. I'm aware of 'forced' mode, however on my platform busybox's rmmod isn't compiled with this option, and my aim is to figure out what descriptors are still being kept and fix it, this is obviously a bug in the module or/and the daemon. – Mark Dec 14 '12 at 13:24
  • 2
    One more thing -- the main problem here is that the number of references to the module, i.e. how many processes are using the module (the 3rd field of /proc/net/modules), isn't zero and thus the module can't be unloaded. Before running the daemon, the reference counter is 0, after the daemon has been launched, the counter goes up to 6, although I'd expect just 3 given that it opens three sockets. So, after killing the damon, the counter goes down to 3, and thus the module can't be unloaded. Are there any ways to catch what other descriptors etc. being kept open? – Mark Dec 14 '12 at 13:27
  • @Mark - this is a separate question. See [this](https://stackoverflow.com/questions/448999/is-there-a-way-to-figure-out-what-is-using-a-linux-kernel-module) and [this](https://stackoverflow.com/questions/9029526/how-to-find-the-list-of-processes-using-a-particular-kernel-module). – Brett Holman Oct 29 '18 at 20:16