DEPRECATED OPTIONS IN INSMOD COMMAND in Linux 2.6 and beyond

Some time ago, I had answered a question from an user regarding the switches available for the insmod command.

Basically, the user wanted to try using the insmod -m option that prevailed during the days of Linux 2.4.
The current man pages for insmod did seem to still display these options, though they have been removed from the days of Linux 2.6.

Below is a summary of the same discussion found in stack overflow:

I try to use insmod "/my/url/fil.ko" -m to debug what happens but each time I got error -1 Unknown symbol in module while in /cat/log/message I can see the error unknown parameter -m



4down voteaccepted

Yes, the init_module function gets called as soon as you load it to the kernel using insmod. You can just add a line of printk and verify it being printed as soon as you insert the module. You cannot pass a parameter such as -m to debug the kernel module. You can only pass parameters that are intended to be handled within the kernel module that you have written, using MODULE_PARAMS. share|edit|delete|flag answered Aug 9 at 17:26 Amarnath Revanna 1063

believe support for the -m switch on insmod was removed starting from kernel 2.6. You can find more info. here:linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/3268.html – Amarnath Revanna Aug 9 at 18:21

UNDERSTANDING THE MACRO __INIT AND __EXIT IN LINUX KERNEL

It is always confusing for people using the macros __init and __exit as to how they can help in kernel memory management.

Recently, I tried to explain the same in one of the mailing list regarding the same, where one of the user wanted to know why these macros are applicable only when they are built as part of the kernel and how freeing memory for a built-in module is truly important as compared to releasing memory in case of a Loadable Kernel Module (LKM).

Here is an excerpt of the same discussion:

Hi Amar,

On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
<amarnath.revanna@gmail.com> wrote:

>
> On the other hand, any other kernel module that you load using insmod or
> modprobe comes after this stage, wherein the kernel was already booted, and
> hence, no memory area of __init will ever be freed.
>

Modules are loaded with vmalloc, right?

Could you explain why the kernel can't free those __init symbols
from memory also in this case?

Thanks,
Ezequiel.

Hi Ezequiel,

When we look at the definition of __init & __initdata in  http://lxr.free-electrons.

com/source/include/linux/init.
h#L44,

  #define __init          __section(.init.text) __cold notrace
  #define __initdata      __section(.init.data)
  #define __initconst     __section(.init.rodata)
  #define __exitdata      __section(.exit.data)
  #define __exit_call     __used __section(.exitcall.exit)

we can notice that the functions represented by __init and any data represented by __initdata are going to be placed 

in a separate section of the final kernel binary image (zImage/uImage/vmlinux)  by the linker.

This section is going to be called the .init section.

The idea behind forming this separate .init section in the final kernel image is to hold all those functions and data structures 

that are going to be required only once during initialization, together.

By doing so, the kernel, once it boots up, would have already utilized all these resources once during bootup sequence and 

hence, can now be released from the memory. As a result, the kernel would simply discard this entire ".init" section from the 

RAM in one go, there by freeing the memory. The amount of memory being freed by removing this section is thus printed in 

the line:

" [1.011596] Freeing unused kernel memory: 664k freed "

Now, when we think about loadable modules, as you rightly said, are loaded into the kernel memory by obtaining the memory 

area from the heap using vmalloc. The interesting thing about this is that, since we are going to load only one module 

within this vmalloc'd area, we can normally expect the size of __initdata and __init function to be pretty small, in few bytes. 

Now, it becomes too difficult for the kernel to manage (keep track of and free) these smaller memory areas coming up from 

every individual loaded module.

Another thing to add is that, in case of freeing up an entire .init section from the RAM, we are recovering the entire .init 

section size'd _contiguous_ physical memory area back to the kernel. However, in case of Loaded Kernel Module (LKM) if we 

try to free up the __init memory of an LKM that was allocated using vmalloc, we may only be freeing up few bytes of memory 

that was virtually contiguous. This may not be of much significance for the kernel operation as compared to its overhead 

involved with managing a process to keep track of and freeing up all these __init memory in vmalloc area.

In short, its kind of a nice trade off done to leave this __init data cleanup for LKM while keeping its significance for all built in 

drivers/modules.

Regards,

-Amar