Re: [PATCH v1 2/2] LoongArch: mm: Expand modules virtual address space to 2GB
From: Tiezhu Yang
Date: Mon Jul 20 2026 - 06:43:05 EST
On 2026/7/19 下午11:28, Xi Ruoyao wrote:
On Sun, 2026-07-19 at 12:01 +0300, Mike Rapoport wrote:
On Fri, Jul 17, 2026 at 03:57:15PM +0800, Tiezhu Yang wrote:
Frequent "execmem: unable to allocate memory" warnings are observed
during kernel module loading when updating the latest kernel.
This is because the modules virtual address region on LoongArch is
tightly constrained to 256MB, while ARM64 and RISC-V are natively
configured with a spacious 2GB region.
The constraint follows architecture ability to address kernel instructions
and data from modules code.
I don't know what are loongarch requirements, but I remember that arm64
added a layer of relocation support to allow 2G module address space.
IIUC on LoongArch the size of one module is limited to 256MB, but the
total size of modules can be up to 2GB, as the module loader creates PLT
entries for calls across the module boundary.
I'd seen the "execmem: unable to allocate memory" error loading the
large amdgpu module. But after I stripped the amdgpu module those
warnings gone away. To me this is very strange: shouldn't the module
loader just ignore the debug info even if it's not stripped instead of
requesting execmem for it???
I did the following changes based on the original 7.2-rc4 for debugging:
```
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 46dd8d25a605..5eab1ab8b195 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2972,7 +2972,6 @@ static struct module *layout_and_allocate(struct load_info *info, int flags)
* special cases for the architectures.
*/
layout_sections(info->mod, info);
- layout_symtab(info->mod, info);
/* Allocate and move to the final place */
err = move_module(info->mod, info);
@@ -3013,9 +3012,6 @@ static int post_relocation(struct module *mod, const struct load_info *info)
percpu_modcopy(mod, (void *)info->sechdrs[info->index.pcpu].sh_addr,
info->sechdrs[info->index.pcpu].sh_size);
- /* Setup kallsyms-specific fields. */
- add_kallsyms(mod, info);
-
/* Arch-specific module finalizing. */
return module_finalize(info->hdr, info->sechdrs, mod);
}
```
With this diff, the "execmem: unable to allocate memory" warnings disappear
completely:
fedora@linux:~/7.2-rc4.git$ dmesg -t | grep "execmem:"
fedora@linux:~/7.2-rc4.git$ readelf -S drivers/gpu/drm/amd/amdgpu/amdgpu.ko | grep -A 1 -E "debug_info|symtab"
[23] .debug_info PROGBITS 0000000000000000 00b73fa9
000000000bfde1bc 0000000000000000 0 0 1
[24] .rela.debug_info RELA 0000000000000000 280f2e40
0000000011f754a8 0000000000000018 I 75 23 8
--
[75] .symtab SYMTAB 0000000000000000 18934e78
000000000f1a0dd8 0000000000000018 76 10548226 8
This test proves that the "execmem: unable to allocate memory" warning is
entirely triggered by the massive unstripped .symtab section (~241.63 MB)
rather than the debug sections themselves.
As the readelf data shows, the ~500MB debug sections remain fully present
in the static file, yet the memory allocation succeeds without any errors.
This confirms that the generic loader successfully ignores non-SHF_ALLOC
sections during layout_sections().
However, layout_symtab() must put the massive .symtab into memory to
support kallsyms and oops backtraces. Combined with the driver core code,
the total memory request reaches ~252.86 MB. This immediately triggers
allocation failures because 252.86 MB is too close to the narrow 256MB
limit on LoongArch, especially when virtual memory fragmentation exists.
We cannot strip modules or remove layout_symtab() because we need
backtrace symbols for debugging. Therefore, the ~252MB memory demand is
a hard requirement, and expanding MODULES_END to 2GB is necessary for
large modern drivers on LoongArch.
Thanks,
Tiezhu