Okay, will follow that protocol. This update is to replace the vmalloc range parameters in the overflow warning message to be between vstart and vend.
________________________________________ From: Andrew Morton <[email protected]> Sent: Tuesday, June 11, 2024 12:57 PM To: Shubhang Kaushik OS Cc: [email protected]; Uladzislau Rezki; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matthew Wilcox Subject: Re: [PATCH v5] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics On Tue, 11 Jun 2024 19:38:44 +0000 Shubhang Kaushik OS <[email protected]> wrote: > 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' > The above warning is seen in the kernel functionality for allocation of the > restricted virtual memory range till exhaustion. > > This message is misleading because 'vmalloc=' is supported on arm32, x86 > platforms and is not a valid kernel parameter on a number of other platforms > (in particular its not supported on arm64, alpha, loongarch, arc, csky, > hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, > um, xtensa, s390, sparc). With the update, the output gets modified to > include the function parameters along with the start and end of the virtual > memory range allowed. > > The warning message after fix on kernel version 6.10.0-rc1+: > > vmalloc_node_range for size 33619968 failed: Address range restricted between > 0xffff800082640000 - 0xffff800084650000 > > Backtrace with the misleading error message: > > vmap allocation for size 33619968 failed: use vmalloc=<size> to > increase size > insmod: vmalloc error: size 33554432, vm_struct allocation failed, > mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 > CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ > #79 > Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan > Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd > Call trace: > dump_backtrace+0xa0/0x128 > show_stack+0x20/0x38 > dump_stack_lvl+0x78/0x90 > dump_stack+0x18/0x28 > warn_alloc+0x12c/0x1b8 > __vmalloc_node_range_noprof+0x28c/0x7e0 > custom_init+0xb4/0xfff8 [test_driver] > do_one_initcall+0x60/0x290 > do_init_module+0x68/0x250 > load_module+0x236c/0x2428 > init_module_from_file+0x8c/0xd8 > __arm64_sys_finit_module+0x1b4/0x388 > invoke_syscall+0x78/0x108 > el0_svc_common.constprop.0+0x48/0xf0 > do_el0_svc+0x24/0x38 > el0_svc+0x3c/0x130 > el0t_64_sync_handler+0x100/0x130 > el0t_64_sync+0x190/0x198 When sending an updated version, please describe what was changed since the previous version. After the changelog's ^---$ separator is the usual place. I'm seeing this: --- a/mm/vmalloc.c~vmalloc-modify-the-alloc_vmap_area-error-message-for-better-diagnostics-v5 +++ a/mm/vmalloc.c @@ -2057,7 +2057,7 @@ overflow: if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit()) pr_warn("vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx\n", - size, addr, addr+size); + size, vstart, vend); kmem_cache_free(vmap_area_cachep, va); return ERR_PTR(-EBUSY); _ which I assume has no effect?
