将模块移植到较新的Linux内核:无法分配内存

cal*_*doa 5 c kernel insmod linux-kernel vmalloc

我有一个非常大的驱动程序模块,我正在尝试编译最近的Linux内核(3.4.4).我可以insmod使用2.6.27.25内核成功编译和使用相同的模块.GCC版本也不同,4.7.0对4.3.0.请注意,此模块非常复杂,我不能简单地浏览所有代码和所有makefile.

当"插入"模块时,我得到一个Cannot allocate memory带有以下痕迹:

vmap allocation for size 30248960 failed: use vmalloc=<size> to increase size.
vmalloc: allocation failure: 30243566 bytes
insmod: page allocation failure: order:0, mode:0xd2
Pid: 5840, comm: insmod Tainted: G           O 3.4.4-5.fc17.i686 #1
Call Trace:
 [<c092702a>] ? printk+0x2d/0x2f
 [<c04eff8d>] warn_alloc_failed+0xad/0xf0
 [<c05178d9>] __vmalloc_node_range+0x169/0x1d0
 [<c0517994>] __vmalloc_node+0x54/0x60
 [<c0490825>] ? sys_init_module+0x65/0x1d80
 [<c0517a60>] vmalloc+0x30/0x40
 [<c0490825>] ? sys_init_module+0x65/0x1d80
 [<c0490825>] sys_init_module+0x65/0x1d80
 [<c050cda6>] ? handle_mm_fault+0xf6/0x1d0
 [<c0932b30>] ? spurious_fault+0xae/0xae
 [<c0932ce7>] ? do_page_fault+0x1b7/0x450
 [<c093665f>] sysenter_do_call+0x12/0x28
-- clip --
Run Code Online (Sandbox Code Playgroud)

显而易见的答案似乎是模块分配了太多内存,但是:

  • 我对旧内核版本没有任何问题,这个模块的大小
  • 如果我修剪这个模块的某些部分以获得更低的内存消耗,我会得到与新内核相同的错误消息
  • 我可以卸载很多其他模块,但它没有任何影响(并且无论如何相关?Linux是否存在关于模块总内存使用量的全局限制)

因此,我怀疑新内核的问题与有限的内存没有直接关系.

新内核抱怨vmalloc()30,000 KB,但是使用旧内核,lsmod给我的大小为4,800 KB.这些数字应该直接相关吗?是否有可能在构建过程中出现问题并且要求RAM太多?当我编译两个部分的大小时.ko,我没有看到很大的差异.

所以我试图了解问题的来源.当我检查转储堆栈时,我无法找到匹配的代码段.似乎故障vmalloc()是由sys_init_module(),init_module()来自kernel/module.c.但代码不匹配.当我从我检查目标代码时.ko,init_module()代码也不匹配.

我或多或少被阻止,因为我不太了解内核,并且所有构建系统和模块加载都很难理解.在加载模块之前发生错误,因为我怀疑某些功能缺失并且此时insmod不报告这些错误.

ugo*_*ren 5

我相信分配是在完成的layout_and_allocate,这被称为load_module.两者都是静态函数,因此它们可能是内联的,因此不在堆栈中.
所以它不是由您的代码完成的分配,而是由Linux完成的分配以加载您的代码.

如果你的旧内核是4.8MB而新的内核是30MB,它可以解释它失败的原因.
所以问题是为什么它如此之大.

大小可能是由于代码量(不太可能增长太多)或静态分配的数据.
一个可能的解释是你有一个大的静态分配数组,其大小在Linux中定义.如果大小显着增加,您的阵列将会增长.
一个猜测 - 一个大小为的数组NR_CPUS.

您应该能够使用诸如nm或之objdump类的命令来查找这样的数组.但是我不知道究竟是怎么做到的.