Re: [PATCH v1 2/2] LoongArch: mm: Expand modules virtual address space to 2GB

[Tiezhu Yang <yangtiezhu@loongson.cn>]

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