1

I cannot rmmode a scull:

# /sbin/rmmod scull
rmmod: ERROR: Module scull is in use

# /sbin/modprobe scull
modprobe: FATAL: Module scull not found in directory /lib/modules/4.19.0-9-amd64

Ok, so the scull is in use, but is not in modules dir? Do not get it.

#depmod #maybe it needs to inform kernel?

but to no avail (still get the errors above). Why?

the question comes from my previous one How to build external modules in ubuntu? regarding loading module (not successfuly) and the output of the kern log. Now, when I have reacted to comment from the link to add printk to init function (as a kind of "debuging" option), I needed to first remove the old module. But when did - the error above. From other stack-question, there were answer to use modprobe -r. I have tried that as well, but to no avail. So now I am confused how to remove module without to reboot or force to do (rmmod -f). This should be general question (how to remove module, when kernel does not know about it), not specific to my module, but I do not know whether it is possible to answer without knowing the specific case I am in. Nevertheless, does the module in use means being in the /lib/modules dir that modprobe refers?

autistic456
  • 183
  • 1
  • 10
  • Shall we guess or you can add a bit more information? – 0andriy May 25 '20 at 22:46
  • will edit...... – autistic456 May 25 '20 at 23:03
  • "Ok, so the scull is in use, but is not in modules dir?" - Have you **installed** your module into `/lib/modules/4.19.0-9-amd64`? Otherwise, why do you expect to find it there? Anyway, `modprobe` is just a wrapper around `insmod` and `rmmod` utilities. If `rmmod` cannot remove the module, then `modprobe` cannot do that too. If your module has caused "Killed" for an application, then you are unlikely be able to remove such module. The harm to the kernel is already done, so it is better to reboot the system. – Tsyvarev Jun 07 '20 at 09:40
  • @Tsyvarev then I hope kernel does not feel the pain, and stay stronger even in these tough times, as we do. – autistic456 Jun 07 '20 at 09:51
  • Well, more detailed description: The kernel still works, except some of its parts. E.g. the part which is responsible for the file, created by your `scull` driver, is **broken**: it is in "opened" state, but no one can close it. Unloading your module requires to close this file, but even the kernel cannot do that. – Tsyvarev Jun 07 '20 at 10:00
  • @Tsyvarev that sucks – autistic456 Jun 07 '20 at 10:00
  • You are programming in the kernel space, and should be aware that your code could **harm the entire system**. The kernel is designed so that most disastrous effects, like corrupting hardware, corrupting a hard disk, are *unlikely* to happen. So on crash the kernel effectively disables some parts: this stops damage propagation. – Tsyvarev Jun 07 '20 at 10:06
  • @Tsyvarev you see, how smart kernel is? – autistic456 Jun 07 '20 at 10:08
  • Yes, the kernel is actually smart: After a crash it prevents you from doing more damage to the system. – Tsyvarev Jun 07 '20 at 10:10
  • @Tsyvarev, but it could be even smarter, when it starts damage itself, and cause e.g. kernel panic. These are really death situation – autistic456 Jun 07 '20 at 10:20
  • You may configure the kernel in a way, when any kernel error will result in a kernel panic. But you would unlikely find this configuration useful when write your kernel module and debug it. – Tsyvarev Jun 07 '20 at 10:22
  • @Tsyvarev, I do not have yet the skill to debug a device. I can debug some users program, but not even a simple device, since it is still complex – autistic456 Jun 07 '20 at 10:23
  • This is most likely because the module isn't exactly running. try running `cat /proc/modules | grep scull` and you will see it's status on the right – Bl4ckC4t May 16 '21 at 19:27

0 Answers0