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

[Mike Rapoport <rppt@kernel.org>]

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.