代码拉取完成，页面将自动刷新
[root@localhost245 ~]# cat /etc/openEuler-latest
openeulerversion=openEuler-21.03
compiletime=2021-03-30-18-46-12
gccversion=9.3.1-20210204.16.oe1
kernelversion=5.10.0-4.17.0.28.oe1
openjdkversion=1.8.0.282.b08-8.oe1
[ 17.449509] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.449528] systemd-udevd: vmalloc: allocation failure: 327680 bytes, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-3
[ 17.449563] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.449567] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.449670] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.450204] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.450393] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.451326] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
[ 17.451466] vmap allocation for size 393216 failed: use vmalloc=<size> to increase size
系统启动报vmalloc分配内存失败了，想查看vmalloc总共的内存是多少，按报错在启动参数增加vmalloc的内存解决报错问题，但是查看了/proc/meminfo的VmallocTotal之后不知道该加到多大， 看到VmallocTotal值过于大，超过了MemTotal的值
[root@localhost245 ~]# cat /proc/meminfo
MemTotal: 901810368 kB
MemFree: 851857600 kB
MemAvailable: 867066688 kB
Buffers: 332736 kB
Cached: 18553216 kB
SwapCached: 0 kB
Active: 12110528 kB
Inactive: 18328320 kB
Active(anon): 9960832 kB
Inactive(anon): 1679360 kB
Active(file): 2149696 kB
Inactive(file): 16648960 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 41942976 kB
SwapFree: 41942976 kB
Dirty: 192 kB
Writeback: 0 kB
AnonPages: 11553024 kB
Mapped: 107904 kB
Shmem: 87488 kB
KReclaimable: 758336 kB
Slab: 3040448 kB
SReclaimable: 758336 kB
SUnreclaim: 2282112 kB
KernelStack: 167552 kB
PageTables: 42560 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 492848128 kB
Committed_AS: 20362560 kB
VmallocTotal: 128982974400 kB
VmallocUsed: 711808 kB
VmallocChunk: 0 kB
Percpu: 475136 kB
HardwareCorrupted: 0 kB
AnonHugePages: 8912896 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
CmaTotal: 524288 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 524288 kB
Hugetlb: 0 kB
Hey jpzhang187, Welcome to openEuler Community.
All of the projects in openEuler Community are maintained by @openeuler-ci-bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md to find the details.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
启动阶段 percpu 的数据把 vmalloc 区域消耗完了。导致后续驱动继续使用 vmalloc 进行分配失败。
如下打印说明，percpu 的数据已经消耗了 VMALLOC_TOTAL 的 3/4
# cat dmesg.txt | grep percpu
[ 0.000000] percpu: max_distance=0x5fcfdc640000 too large for vmalloc space 0x781fefff0000
[ 0.000000] percpu: Embedded 10 pages/cpu s586200 r8192 d60968 u655360
在函数 pcpu_embed_first_chunk 中发现
在函数的最后会调用 pcpu_free_alloc_info 释放空间。
udev 配置了 children_max = 5 后
日志里面就没看到这些报错了。
日志参照 journal_new.log
验证4.19，5.10，以及主线内核版本均有这个问题，因为openeuler的模块比较多，而commit b2eed9b58811 ("arm64/kernel: kaslr: reduce module randomization range to 2 GB")把module vmalloc的范围限制在2G，查看
/proc/vmallocinfo确认改地址段的区域确实被用完了。
当还有kernel module需要分配内存时，__alloc_vmap_area处便会失败，因为分配的vmalloc区域超过了限定的范围，从而报错。简单将arch/arm64/kernel/module.c中module_alloc传的SZ_2G改回之前SZ_4G便不会出现上述vmalloc失败的问题。
但这是属于主线上的bug，需要分析对__ksymtab entries的影响以及CONFIG_HAVE_ARCH_PREL32_RELOCATIONS涉及的修改。后续将先发补丁跟社区交流后面再回合到openeuler。
ARM64 ADRP 指令无法处理超过 4G 的偏移。开启了 KASLR 之后, 内核也将在 VMALLOC 区域内, 这样为了防止内核和模块之间距离便宜过大，导致 ADRP 无法重定向和解析。因此
f2b9ba871beb arm64/kernel: kaslr: reduce module randomization range to 4 GB
更进一步的，在 commit 7290d5809571 ("module: use relative references for __ksymtab entries") 之后更新了一些具有KASLR功能的体系结构的ksymtab处理，使ksymtab条目以32位相对引用对的形式发出。这减少了条目的大小，但更重要的是，它消除了静态分配的绝对地址，如果内核正在进行自重定位(它为ksymtab结构的每个成员取一个24字节的RELA条目)，则需要在引导时进行重定向。
但是并不能假定32位相对引用始终足以捕获ksymtab条目与其目标符号之间的偏移量，因此要求进一步缩小模块随机化范围，将核心内核置于引用每CPU变量的模块ksymtab项的32位相对引用的-/+2GB范围之内。
b2eed9b58811 arm64/kernel: kaslr: reduce module randomization range to 2 GB
验证4.19，5.10，以及主线内核版本均有这个问题，因为openeuler的模块比较多，而commit b2eed9b58811 ("arm64/kernel: kaslr: reduce module randomization range to 2 GB")把module vmalloc的范围限制在2G，查看
/proc/vmallocinfo确认改地址段的区域确实被用完了。当还有kernel module需要分配内存时，__alloc_vmap_area处便会失败，因为分配的vmalloc区域超过了限定的范围，从而报错。简单将arch/arm64/kernel/module.c中module_alloc传的SZ_2G改回之前SZ_4G便不会出现上述vmalloc失败的问题。
但这是属于主线上的bug，需要分析对__ksymtab entries的影响以及CONFIG_HAVE_ARCH_PREL32_RELOCATIONS涉及的修改。后续将先发补丁跟社区交流后面再回合到openeuler。
@刘勇强 回合到openeuler内核之后，麻烦将补丁链接补充到评论区
这个问题扩展vmalloc区域不可行，和已有特性冲突太大
您好，由于这个issue两周内没有反馈解决情况，并且kernel已经给出分析结论，按照社区处理流程，先将issue关闭，后续有疑问可以重新开启。
登录 后才可以发表评论