Re: [PATCH v1 1/2] mm/execmem: Print size, align and caller on allocation failure

Re: [PATCH v1 1/2] mm/execmem: Print size, align and caller on allocation failure

[Andrew Morton]

On Fri, 17 Jul 2026 15:57:14 +0800 Tiezhu Yang <yangtiezhu@loongson.cn> wrote:

> The current execmem_vmalloc() function reports an allocation failure
> with a simplistic "unable to allocate memory" message. This notifies
> the user that an error occurred, but it acts as a black box during
> debugging.
> 
> Enhance pr_warn_ratelimited() within execmem_vmalloc() to explicitly
> print the requested allocation size, alignment constraints, and the
> symbolic caller.
> 
> This diagnostic visibility is valuable for analyzing the root cause
> of allocation failures and tracking misbehaving subsystems without
> inducing log pollution.

Have you actually encountered this?  GFP_KERNEL allocation failures are
supposed to be very rare.

> ...
>
> --- a/mm/execmem.c
> +++ b/mm/execmem.c
> @@ -50,7 +50,9 @@ static void *execmem_vmalloc(struct execmem_range *range, size_t size,
>  	}
>  
>  	if (!p) {
> -		pr_warn_ratelimited("unable to allocate memory\n");
> +		pr_warn_ratelimited("unable to allocate memory, "
> +				    "size=%zu, align=%u, caller is %pS\n",
> +				     size, align, __builtin_return_address(0));
>  		return NULL;
>  	}

This seems to be duplicating the information which the page allocator
can emit.  Perhaps we should remove the __GFP_NOWARN in there?

Re: [PATCH v1 1/2] mm/execmem: Print size, align and caller on allocation failure

[Mike Rapoport]

On Fri, Jul 17, 2026 at 11:37:30AM -0700, Andrew Morton wrote:
> On Fri, 17 Jul 2026 15:57:14 +0800 Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> 
> > The current execmem_vmalloc() function reports an allocation failure
> > with a simplistic "unable to allocate memory" message. This notifies
> > the user that an error occurred, but it acts as a black box during
> > debugging.
> > 
> > Enhance pr_warn_ratelimited() within execmem_vmalloc() to explicitly
> > print the requested allocation size, alignment constraints, and the
> > symbolic caller.
> > 
> > This diagnostic visibility is valuable for analyzing the root cause
> > of allocation failures and tracking misbehaving subsystems without
> > inducing log pollution.
> 
> Have you actually encountered this?  GFP_KERNEL allocation failures are
> supposed to be very rare.

Looking at the second patch, it's quite possible. The allocation is limited
to module addresses which was only 256M on loongarch and could have been
exhausted.

> > ...
> >
> > --- a/mm/execmem.c
> > +++ b/mm/execmem.c
> > @@ -50,7 +50,9 @@ static void *execmem_vmalloc(struct execmem_range *range, size_t size,
> >  	}
> >  
> >  	if (!p) {
> > -		pr_warn_ratelimited("unable to allocate memory\n");
> > +		pr_warn_ratelimited("unable to allocate memory, "
> > +				    "size=%zu, align=%u, caller is %pS\n",
> > +				     size, align, __builtin_return_address(0));
> >  		return NULL;
> >  	}
> 
> This seems to be duplicating the information which the page allocator
> can emit.  Perhaps we should remove the __GFP_NOWARN in there?

Right, page allocator/vmalloc reports would be more useful, for example

"vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx"

was most probably the cause of allocation failures.

But we cannot remove __GFP_NOWARN unconditionally though, because execmem has
fallbacks for some of the allocation failures and I don't think the
complexity required to detect when __GFP_NOWARN should be cleared does not
justify one-off case.

Besides, nowadays there are other tools (e.g. BPF based) except printk that
allow debugging such issue, so I don't see much value in extending this
error message or clearing __GFP_NOWARN sometimes.

-- 
Sincerely yours,
Mike.

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

[Mike Rapoport]

Hi,

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.

> Expand the modules virtual address space to 2GB for LoongArch to
> eliminate these allocation bottlenecks.
> 
> This change only applies to 64-bit kernels (CONFIG_64BIT), 32-bit
> kernels (CONFIG_32BIT) are entirely unaffected since they do not
> define separate module address regions.
> 
> With this patch, there are no "execmem: unable to allocate memory"
> warnings anymore for 64-bit kernels.
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
>  arch/loongarch/include/asm/pgtable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/include/asm/pgtable.h
> index 223528c04d73..e5952ecd6a73 100644
> --- a/arch/loongarch/include/asm/pgtable.h
> +++ b/arch/loongarch/include/asm/pgtable.h
> @@ -96,7 +96,7 @@ struct vm_area_struct;
>  #ifdef CONFIG_64BIT
>  
>  #define MODULES_VADDR	(vm_map_base + PCI_IOSIZE + (2 * PAGE_SIZE))
> -#define MODULES_END	(MODULES_VADDR + SZ_256M)
> +#define MODULES_END	(MODULES_VADDR + SZ_2G)
>  
>  #ifdef CONFIG_KFENCE
>  #define KFENCE_AREA_SIZE	(((CONFIG_KFENCE_NUM_OBJECTS + 1) * 2 + 2) * PAGE_SIZE)
> -- 
> 2.42.0
> 

-- 
Sincerely yours,
Mike.

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

[Xi Ruoyao]

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???

-- 
Xi Ruoyao <xry111@xry111.site>

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

[Tiezhu Yang]

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???

Yes, after "strip --strip-debug drivers/gpu/drm/amd/amdgpu/amdgpu.ko",
there are no "execmem: unable to allocate memory" warnings anymore.

But we usually need the debuginfo, here are the details:

$ readelf -S drivers/gpu/drm/amd/amdgpu/amdgpu.ko
There are 78 section headers, starting at offset 0x3acdf0a0:

Section Headers:
   [Nr] Name              Type             Address           Offset
        Size              EntSize          Flags  Link  Info  Align
   ...
   [23] .debug_info       PROGBITS         0000000000000000  00b73fa9
        000000000bfde1bc  0000000000000000           0     0     1
   [24] .rela.debug_info  RELA             0000000000000000  280f2e40
        0000000011f754a8  0000000000000018   I      75    23     8
   ...


$ objdump -h drivers/gpu/drm/amd/amdgpu/amdgpu.ko

drivers/gpu/drm/amd/amdgpu/amdgpu.ko:     file format elf64-loongarch

Sections:
Idx Name          Size      VMA               LMA               File off 
  Algn
  ...
  14 .debug_info   0bfde1bc  0000000000000000  0000000000000000 
00b73fa9  2**0
                   CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
  ...

The size of .debug_info is 0x0bfde1bc (191.87 MB),
the flag of .debug_info is not SHF_EXECINSTR or SHF_ALLOC.
The size of .rela.debug_info is 0x11f754a8 (287.46 MB),
the flag of .rela.debug_info is I (SHF_INFO_LINK).

Furthermore, I think the following changes are also necessary:

```
diff --git a/arch/loongarch/kernel/module.c b/arch/loongarch/kernel/module.c
index 7d4d571ee55e..5a4cbd27f97d 100644
--- a/arch/loongarch/kernel/module.c
+++ b/arch/loongarch/kernel/module.c
@@ -484,6 +484,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char 
*strtab,
         Elf_Addr v;
         Elf_Sym *sym;
         Elf_Rela *rel = (void *) sechdrs[relsec].sh_addr;
+       Elf_Shdr *dst_sec = sechdrs + sechdrs[relsec].sh_info;

         pr_debug("%s: Applying relocate section %u to %u\n", __func__, 
relsec,
                sechdrs[relsec].sh_info);
@@ -522,6 +523,10 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const 
char *strtab,

                 v = sym->st_value + rel[i].r_addend;

+               /* Skip advanced address pairing for non-exec sections */
+               if (!(dst_sec->sh_flags & SHF_EXECINSTR))
+                       goto apply_normal;
+
                 if (type == R_LARCH_PCADD_LO12 || type == 
R_LARCH_GOT_PCADD_LO12) {
                         bool found = false;
                         unsigned int j = idx;
@@ -562,6 +567,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char 
*strtab,
                         idx = j; /* Record the previous j-loop end index */
                 }

+apply_normal:
                 switch (type) {
                 case R_LARCH_B26:
                         err = apply_r_larch_b26(mod, sechdrs, location,
```

Thanks,
Tiezhu

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

[Tiezhu Yang]

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