Linux-csky Archive mirror
 help / color / mirror / Atom feed
* [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics
@ 2024-06-10 17:22 Shubhang Kaushik OS
  2024-06-11 10:09 ` Uladzislau Rezki
  0 siblings, 1 reply; 4+ messages in thread
From: Shubhang Kaushik OS @ 2024-06-10 17:22 UTC (permalink / raw
  To: ampere-linux-kernel@lists.amperecomputing.com
  Cc: linux-arm-kernel@lists.infradead.org, cl@linux.com,
	corbet@lwn.net, akpm@linux-foundation.org, urezki@gmail.com,
	linux-mm@kvack.org, guoren@kernel.org, linux-doc@vger.kernel.org,
	xiongwei.song@windriver.com, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, willy@infradead.org

'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

Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com>
Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 9 ++++++---
 mm/vmalloc.c                                    | 4 ++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b600df82669d..9b8f8ab90284 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7245,9 +7245,12 @@
 
 	vmalloc=nn[KMG]	[KNL,BOOT,EARLY] Forces the vmalloc area to have an
 			exact size of <nn>. This can be used to increase
-			the minimum size (128MB on x86). It can also be
-			used to decrease the size and leave more room
-			for directly mapped kernel RAM.
+			the minimum size (128MB on x86, arm32 platforms).
+			It can also be used to decrease the size and leave more room
+			for directly mapped kernel RAM. Note that this parameter does
+			not exist on many other platforms (including arm64, alpha,
+			loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc,
+			parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc).
 
 	vmcp_cma=nn[MG]	[KNL,S390,EARLY]
 			Sets the memory size reserved for contiguous memory
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5d3aa2dc88a8..75ad551e90ba 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2055,8 +2055,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
 	}
 
 	if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
-		pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
-			size);
+		pr_warn("vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx\n",
+				size, addr, addr+size);
 
 	kmem_cache_free(vmap_area_cachep, va);
 	return ERR_PTR(-EBUSY);
-- 
2.39.2

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics
  2024-06-10 17:22 [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics Shubhang Kaushik OS
@ 2024-06-11 10:09 ` Uladzislau Rezki
  2024-06-11 17:44   ` Shubhang Kaushik OS
  0 siblings, 1 reply; 4+ messages in thread
From: Uladzislau Rezki @ 2024-06-11 10:09 UTC (permalink / raw
  To: Shubhang Kaushik OS
  Cc: ampere-linux-kernel@lists.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org, cl@linux.com,
	corbet@lwn.net, akpm@linux-foundation.org, urezki@gmail.com,
	linux-mm@kvack.org, guoren@kernel.org, linux-doc@vger.kernel.org,
	xiongwei.song@windriver.com, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, willy@infradead.org

On Mon, Jun 10, 2024 at 05:22:58PM +0000, Shubhang Kaushik OS 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
> 
> Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com>
> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 9 ++++++---
>  mm/vmalloc.c                                    | 4 ++--
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b600df82669d..9b8f8ab90284 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7245,9 +7245,12 @@
>  
>  	vmalloc=nn[KMG]	[KNL,BOOT,EARLY] Forces the vmalloc area to have an
>  			exact size of <nn>. This can be used to increase
> -			the minimum size (128MB on x86). It can also be
> -			used to decrease the size and leave more room
> -			for directly mapped kernel RAM.
> +			the minimum size (128MB on x86, arm32 platforms).
> +			It can also be used to decrease the size and leave more room
> +			for directly mapped kernel RAM. Note that this parameter does
> +			not exist on many other platforms (including arm64, alpha,
> +			loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc,
> +			parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc).
>  
>  	vmcp_cma=nn[MG]	[KNL,S390,EARLY]
>  			Sets the memory size reserved for contiguous memory
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 5d3aa2dc88a8..75ad551e90ba 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2055,8 +2055,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>  	}
>  
>  	if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
> -		pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
> -			size);
> +		pr_warn("vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx\n",
> +				size, addr, addr+size);
>
One question. I see that you would like to see the range, i.e. its "start"
and "end" addresses for failure case. For such purpose, why do not you use
"vstart" and "vend" variables which specify a range?

An "addr" points here on "vend". Or is this intentional?

Sorry for late looking at this. I was on a vacation last week.

--
Uladzislau Rezki

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics
  2024-06-11 10:09 ` Uladzislau Rezki
@ 2024-06-11 17:44   ` Shubhang Kaushik OS
  2024-06-11 18:05     ` Uladzislau Rezki
  0 siblings, 1 reply; 4+ messages in thread
From: Shubhang Kaushik OS @ 2024-06-11 17:44 UTC (permalink / raw
  To: Uladzislau Rezki
  Cc: ampere-linux-kernel@lists.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org, cl@linux.com,
	corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org,
	guoren@kernel.org, linux-doc@vger.kernel.org,
	xiongwei.song@windriver.com, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, willy@infradead.org

This is intentional.  When 'addr' equals 'vend' the overflow path is triggered, but then the 'vstart' and 'vend' values are not carried in the overflow path - making them point to no address. That is the reason 'addr' is used in the warning message to specify the restrictive range - that gets assigned to 'va_start' and 'va_end' in the ideal case.

Shubhang Kaushik

________________________________________
From: Uladzislau Rezki <urezki@gmail.com>
Sent: Tuesday, June 11, 2024 3:09 AM
To: Shubhang Kaushik OS
Cc: ampere-linux-kernel@lists.amperecomputing.com; linux-arm-kernel@lists.infradead.org; cl@linux.com; corbet@lwn.net; akpm@linux-foundation.org; urezki@gmail.com; linux-mm@kvack.org; guoren@kernel.org; linux-doc@vger.kernel.org; xiongwei.song@windriver.com; linux-riscv@lists.infradead.org; linux-csky@vger.kernel.org; willy@infradead.org
Subject: Re: [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics

On Mon, Jun 10, 2024 at 05:22:58PM +0000, Shubhang Kaushik OS 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
>
> Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com>
> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 9 ++++++---
>  mm/vmalloc.c                                    | 4 ++--
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b600df82669d..9b8f8ab90284 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7245,9 +7245,12 @@
>
>       vmalloc=nn[KMG] [KNL,BOOT,EARLY] Forces the vmalloc area to have an
>                       exact size of <nn>. This can be used to increase
> -                     the minimum size (128MB on x86). It can also be
> -                     used to decrease the size and leave more room
> -                     for directly mapped kernel RAM.
> +                     the minimum size (128MB on x86, arm32 platforms).
> +                     It can also be used to decrease the size and leave more room
> +                     for directly mapped kernel RAM. Note that this parameter does
> +                     not exist on many other platforms (including arm64, alpha,
> +                     loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc,
> +                     parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc).
>
>       vmcp_cma=nn[MG] [KNL,S390,EARLY]
>                       Sets the memory size reserved for contiguous memory
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 5d3aa2dc88a8..75ad551e90ba 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2055,8 +2055,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>       }
>
>       if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
> -             pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
> -                     size);
> +             pr_warn("vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx\n",
> +                             size, addr, addr+size);
>
One question. I see that you would like to see the range, i.e. its "start"
and "end" addresses for failure case. For such purpose, why do not you use
"vstart" and "vend" variables which specify a range?

An "addr" points here on "vend". Or is this intentional?

Sorry for late looking at this. I was on a vacation last week.

--
Uladzislau Rezki

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics
  2024-06-11 17:44   ` Shubhang Kaushik OS
@ 2024-06-11 18:05     ` Uladzislau Rezki
  0 siblings, 0 replies; 4+ messages in thread
From: Uladzislau Rezki @ 2024-06-11 18:05 UTC (permalink / raw
  To: Shubhang Kaushik OS
  Cc: Uladzislau Rezki, ampere-linux-kernel@lists.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org, cl@linux.com,
	corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org,
	guoren@kernel.org, linux-doc@vger.kernel.org,
	xiongwei.song@windriver.com, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, willy@infradead.org

>
> This is intentional.  When 'addr' equals 'vend' the overflow path is triggered, but then the 'vstart' and 'vend'
> values are not carried in the overflow path - making them point to no address. That is the reason 'addr' is used
> in the warning message to specify the restrictive range - that gets assigned to 'va_start' and 'va_end' in the ideal case.
> 
What do you mean when you say:
"but then the 'vstart' and 'vend' values are not carried in the overflow path - making them point to no address."

From your commit message: "With the update, the output gets modified to
include the function parameters along with the start and end of the virtual
memory range allowed."

i see that you would like to print an allowed range. Thus an allowed
range is specified by "vstart" and "vend", i.e.:


      vstart  vend
<-------|------|------> vmap spase

an allocation must be served between "vstart" and "vend". So, according to
your commit message that range should be printed in case of error.

Now you print, "vend" address and "vend + size" one. I do not follow why
you need it. Could you please explain?

--
Uladzislau Rezki

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-06-11 18:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-10 17:22 [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics Shubhang Kaushik OS
2024-06-11 10:09 ` Uladzislau Rezki
2024-06-11 17:44   ` Shubhang Kaushik OS
2024-06-11 18:05     ` Uladzislau Rezki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).