[PATCH v1 0/2] Enhance execmem diagnostic and fix LoongArch module bottleneck

[PATCH v1 0/2] Enhance execmem diagnostic and fix LoongArch module bottleneck

[Tiezhu Yang]

This series enhances the visual diagnostics for execmem allocation
failures and addresses a practical module space exhaustion issue
on LoongArch.

Tiezhu Yang (2):
  mm/execmem: Print size, align and caller on allocation failure
  LoongArch: mm: Expand modules virtual address space to 2GB

 arch/loongarch/include/asm/pgtable.h | 2 +-
 mm/execmem.c                         | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.42.0

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

[Tiezhu Yang]

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.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 mm/execmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/execmem.c b/mm/execmem.c
index 084a207e4278..f3bc68e0eb98 100644
--- 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;
 	}
 
-- 
2.42.0

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

[Tiezhu Yang]

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.

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

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?