From: "Miquel Sabaté Solà" <mikisabate@gmail.com>
To: paul.walmsley@sifive.com
Cc: aou@eecs.berkeley.edu, linux-kernel@vger.kernel.org,
jeremy.linton@arm.com, palmer@dabbelt.com,
cuiyunhui@bytedance.com, sudeep.holla@arm.com,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH] riscv: Prevent a bad reference count on CPU nodes
Date: Mon, 30 Sep 2024 14:35:05 +0200 [thread overview]
Message-ID: <66fa9afe.5d0a0220.323a97.bfb6@mx.google.com> (raw)
In-Reply-To: <20240913080053.36636-1-mikisabate@gmail.com> ("Miquel Sabaté Solà"'s message of "Fri, 13 Sep 2024 10:00:52 +0200")
[-- Attachment #1.1: Type: text/plain, Size: 2146 bytes --]
On dv., de set. 13 2024, Miquel Sabaté Solà wrote:
> When populating cache leaves we previously fetched the CPU device node
> at the very beginning. But when ACPI is enabled we go through a
> specific branch which returns early and does not call 'of_node_put' for
> the node that was acquired.
>
> Since we are not using a CPU device node for the ACPI code anyways, we
> can simply move the initialization of it just passed the ACPI block, and
> we are guaranteed to have an 'of_node_put' call for the acquired node.
> This prevents a bad reference count of the CPU device node.
>
> Moreover, the previous function did not check for errors when acquiring
> the device node, so a return -ENOENT has been added for that case.
>
> Signed-off-by: Miquel Sabaté Solà <mikisabate@gmail.com>
> ---
> I was wondering if this should also be sent to stable, but I have not seen
> a report on it, and this is not responsible for an oops or anything like that.
> So in the end I decided not to, but maybe you consider otherwise.
>
> arch/riscv/kernel/cacheinfo.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index d6c108c50cba..d32dfdba083e 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -75,8 +75,7 @@ int populate_cache_leaves(unsigned int cpu)
> {
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> - struct device_node *np = of_cpu_device_node_get(cpu);
> - struct device_node *prev = NULL;
> + struct device_node *np, *prev;
> int levels = 1, level = 1;
>
> if (!acpi_disabled) {
> @@ -100,6 +99,10 @@ int populate_cache_leaves(unsigned int cpu)
> return 0;
> }
>
> + np = of_cpu_device_node_get(cpu);
> + if (!np)
> + return -ENOENT;
> +
> if (of_property_read_bool(np, "cache-size"))
> ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
> if (of_property_read_bool(np, "i-cache-size"))
Gently ping :)
Could you take a look at this fix?
Thanks,
Miquel
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 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: "Miquel Sabaté Solà" <mikisabate@gmail.com>
To: paul.walmsley@sifive.com
Cc: palmer@dabbelt.com, aou@eecs.berkeley.edu,
cuiyunhui@bytedance.com, sudeep.holla@arm.com,
jeremy.linton@arm.com, sunilvl@ventanamicro.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: Prevent a bad reference count on CPU nodes
Date: Mon, 30 Sep 2024 14:35:05 +0200 [thread overview]
Message-ID: <66fa9afe.5d0a0220.323a97.bfb6@mx.google.com> (raw)
In-Reply-To: <20240913080053.36636-1-mikisabate@gmail.com> ("Miquel Sabaté Solà"'s message of "Fri, 13 Sep 2024 10:00:52 +0200")
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
On dv., de set. 13 2024, Miquel Sabaté Solà wrote:
> When populating cache leaves we previously fetched the CPU device node
> at the very beginning. But when ACPI is enabled we go through a
> specific branch which returns early and does not call 'of_node_put' for
> the node that was acquired.
>
> Since we are not using a CPU device node for the ACPI code anyways, we
> can simply move the initialization of it just passed the ACPI block, and
> we are guaranteed to have an 'of_node_put' call for the acquired node.
> This prevents a bad reference count of the CPU device node.
>
> Moreover, the previous function did not check for errors when acquiring
> the device node, so a return -ENOENT has been added for that case.
>
> Signed-off-by: Miquel Sabaté Solà <mikisabate@gmail.com>
> ---
> I was wondering if this should also be sent to stable, but I have not seen
> a report on it, and this is not responsible for an oops or anything like that.
> So in the end I decided not to, but maybe you consider otherwise.
>
> arch/riscv/kernel/cacheinfo.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index d6c108c50cba..d32dfdba083e 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -75,8 +75,7 @@ int populate_cache_leaves(unsigned int cpu)
> {
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> - struct device_node *np = of_cpu_device_node_get(cpu);
> - struct device_node *prev = NULL;
> + struct device_node *np, *prev;
> int levels = 1, level = 1;
>
> if (!acpi_disabled) {
> @@ -100,6 +99,10 @@ int populate_cache_leaves(unsigned int cpu)
> return 0;
> }
>
> + np = of_cpu_device_node_get(cpu);
> + if (!np)
> + return -ENOENT;
> +
> if (of_property_read_bool(np, "cache-size"))
> ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
> if (of_property_read_bool(np, "i-cache-size"))
Gently ping :)
Could you take a look at this fix?
Thanks,
Miquel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2024-09-30 13:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 8:00 [PATCH] riscv: Prevent a bad reference count on CPU nodes Miquel Sabaté Solà
2024-09-13 8:00 ` Miquel Sabaté Solà
2024-09-13 9:07 ` Sudeep Holla
2024-09-13 9:07 ` Sudeep Holla
2024-09-18 2:19 ` [External] " yunhui cui
2024-09-18 2:19 ` yunhui cui
2024-09-30 12:35 ` Miquel Sabaté Solà [this message]
2024-09-30 12:35 ` Miquel Sabaté Solà
2024-10-08 13:38 ` Miquel Sabaté Solà
2024-10-08 13:38 ` Miquel Sabaté Solà
2024-10-10 12:29 ` Alexandre Ghiti
2024-10-10 12:29 ` Alexandre Ghiti
2024-10-10 14:32 ` Miquel Sabaté Solà
2024-10-10 14:32 ` Miquel Sabaté Solà
2024-09-30 16:28 ` Sunil V L
2024-09-30 16:28 ` Sunil V L
2024-10-17 16:30 ` patchwork-bot+linux-riscv
2024-10-17 16:30 ` patchwork-bot+linux-riscv
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=66fa9afe.5d0a0220.323a97.bfb6@mx.google.com \
--to=mikisabate@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=cuiyunhui@bytedance.com \
--cc=jeremy.linton@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=sudeep.holla@arm.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.