All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Ley Foon Tan <leyfoon.tan@starfivetech.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ley Foon Tan <lftan.linux@gmail.com>
Subject: Re: [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage
Date: Wed, 4 Jan 2023 13:00:31 +0000	[thread overview]
Message-ID: <Y7V4byskevAWKM3G@spud> (raw)
In-Reply-To: <20230103035316.3841303-1-leyfoon.tan@starfivetech.com>


[-- Attachment #1.1: Type: text/plain, Size: 2775 bytes --]

Hey Ley Foon Tan,

Apologies for my various bits of confusion.

On Tue, Jan 03, 2023 at 11:53:16AM +0800, Ley Foon Tan wrote:
> topology_parse_cpu_capacity() is failed to allocate memory with kcalloc()
> after read "capacity-dmips-mhz" DT parameter in CPU DT nodes. This
> topology_parse_cpu_capacity() is called from init_cpu_topology(), move
> call to init_cpu_topology() to later initialization  stage (after memory
> allocation is available).
> 
> Note, this refers to ARM64 implementation, call init_cpu_topology() in
> smp_prepare_cpus().
> 
> Tested on Qemu platform.

I'd like to suggest a change to the commit message:
```
If "capacity-dmips-mhz" is present in a CPU DT node,
topology_parse_cpu_capacity() will fail to allocate memory.
arm64, with which this code path is shared, does not call
topology_parse_cpu_capacity() until later in boot where memory
allocation is available.
While "capacity-dmips-mhz" is not yet a valid property on RISC-V,
invalid properties should be ignored rather than cause issues.
Move init_cpu_topology(), which calls topology_parse_cpu_capacity(),
to a later initialization stage, to match arm64.

As a side effect of this change, RISC-V is "protected" from changes to
core topology code that would work on arm64 where memory allocation is
safe but on RISC-V isn't.
```

You don't need to use exactly that, but with something along those
lines:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> 
> Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> 
> ---
> 
> In drivers/base/arch_topology.c: topology_parse_cpu_capacity():
> 
> 	ret = of_property_read_u32(cpu_node, "capacity-dmips-mhz",
> 				   &cpu_capacity);
> 	if (!ret) {
> 		if (!raw_capacity) {
> 			raw_capacity = kcalloc(num_possible_cpus(),
> 					       sizeof(*raw_capacity),
> 					       GFP_KERNEL);
> 			if (!raw_capacity) {
> 				cap_parsing_failed = true;
> 				return false;
> 			}
> ---
>  arch/riscv/kernel/smpboot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index 3373df413c88..ddb2afba6d25 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -39,7 +39,6 @@ static DECLARE_COMPLETION(cpu_running);
>  
>  void __init smp_prepare_boot_cpu(void)
>  {
> -	init_cpu_topology();
>  }
>  
>  void __init smp_prepare_cpus(unsigned int max_cpus)
> @@ -48,6 +47,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>  	int ret;
>  	unsigned int curr_cpuid;
>  
> +	init_cpu_topology();
> +
>  	curr_cpuid = smp_processor_id();
>  	store_cpu_topology(curr_cpuid);
>  	numa_store_cpu_info(curr_cpuid);
> -- 
> 2.25.1
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Ley Foon Tan <leyfoon.tan@starfivetech.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ley Foon Tan <lftan.linux@gmail.com>
Subject: Re: [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage
Date: Wed, 4 Jan 2023 13:00:31 +0000	[thread overview]
Message-ID: <Y7V4byskevAWKM3G@spud> (raw)
In-Reply-To: <20230103035316.3841303-1-leyfoon.tan@starfivetech.com>

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

Hey Ley Foon Tan,

Apologies for my various bits of confusion.

On Tue, Jan 03, 2023 at 11:53:16AM +0800, Ley Foon Tan wrote:
> topology_parse_cpu_capacity() is failed to allocate memory with kcalloc()
> after read "capacity-dmips-mhz" DT parameter in CPU DT nodes. This
> topology_parse_cpu_capacity() is called from init_cpu_topology(), move
> call to init_cpu_topology() to later initialization  stage (after memory
> allocation is available).
> 
> Note, this refers to ARM64 implementation, call init_cpu_topology() in
> smp_prepare_cpus().
> 
> Tested on Qemu platform.

I'd like to suggest a change to the commit message:
```
If "capacity-dmips-mhz" is present in a CPU DT node,
topology_parse_cpu_capacity() will fail to allocate memory.
arm64, with which this code path is shared, does not call
topology_parse_cpu_capacity() until later in boot where memory
allocation is available.
While "capacity-dmips-mhz" is not yet a valid property on RISC-V,
invalid properties should be ignored rather than cause issues.
Move init_cpu_topology(), which calls topology_parse_cpu_capacity(),
to a later initialization stage, to match arm64.

As a side effect of this change, RISC-V is "protected" from changes to
core topology code that would work on arm64 where memory allocation is
safe but on RISC-V isn't.
```

You don't need to use exactly that, but with something along those
lines:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> 
> Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> 
> ---
> 
> In drivers/base/arch_topology.c: topology_parse_cpu_capacity():
> 
> 	ret = of_property_read_u32(cpu_node, "capacity-dmips-mhz",
> 				   &cpu_capacity);
> 	if (!ret) {
> 		if (!raw_capacity) {
> 			raw_capacity = kcalloc(num_possible_cpus(),
> 					       sizeof(*raw_capacity),
> 					       GFP_KERNEL);
> 			if (!raw_capacity) {
> 				cap_parsing_failed = true;
> 				return false;
> 			}
> ---
>  arch/riscv/kernel/smpboot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index 3373df413c88..ddb2afba6d25 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -39,7 +39,6 @@ static DECLARE_COMPLETION(cpu_running);
>  
>  void __init smp_prepare_boot_cpu(void)
>  {
> -	init_cpu_topology();
>  }
>  
>  void __init smp_prepare_cpus(unsigned int max_cpus)
> @@ -48,6 +47,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>  	int ret;
>  	unsigned int curr_cpuid;
>  
> +	init_cpu_topology();
> +
>  	curr_cpuid = smp_processor_id();
>  	store_cpu_topology(curr_cpuid);
>  	numa_store_cpu_info(curr_cpuid);
> -- 
> 2.25.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2023-01-04 15:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03  3:53 [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage Ley Foon Tan
2023-01-03  3:53 ` Ley Foon Tan
2023-01-03  6:54 ` Andrew Jones
2023-01-03  6:54   ` Andrew Jones
2023-01-03  7:53   ` Leyfoon Tan
2023-01-03  7:53     ` Leyfoon Tan
2023-01-03 17:07     ` Conor Dooley
2023-01-03 17:07       ` Conor Dooley
2023-01-04  5:35       ` Leyfoon Tan
2023-01-04  5:35         ` Leyfoon Tan
2023-01-04  9:49         ` Conor Dooley
2023-01-04  9:49           ` Conor Dooley
2023-01-04 10:49           ` Sudeep Holla
2023-01-04 10:49             ` Sudeep Holla
2023-01-04 12:18             ` Conor Dooley
2023-01-04 12:18               ` Conor Dooley
2023-01-04 12:56               ` Sudeep Holla
2023-01-04 12:56                 ` Sudeep Holla
2023-01-04 13:24                 ` Conor Dooley
2023-01-04 13:24                   ` Conor Dooley
2023-01-04 10:41       ` Sudeep Holla
2023-01-04 10:41         ` Sudeep Holla
2023-01-04 13:00 ` Conor Dooley [this message]
2023-01-04 13:00   ` Conor Dooley
2023-01-05  1:45   ` Leyfoon Tan
2023-01-05  1:45     ` Leyfoon Tan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7V4byskevAWKM3G@spud \
    --to=conor@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=leyfoon.tan@starfivetech.com \
    --cc=lftan.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.