From: sashiko-bot@kernel.org
To: "Drew Fustini" <fustini@kernel.org>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v2 5/8] riscv_cbqri: resctrl: Add cache allocation via capacity block mask
Date: Thu, 25 Jun 2026 01:53:55 +0000 [thread overview]
Message-ID: <20260625015355.B997D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260624-dfustini-atl-sc-cbqri-dt-v2-5-2f8049fd902b@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Traversing the global `cbqri_controllers` list without holding `cbqri_controllers_lock` during CPU hotplug risks list corruption.
--
commit e1c49060a1fc98c61e36689ccda2041d360bb762
Author: Drew Fustini <fustini@kernel.org>
riscv_cbqri: resctrl: Add cache allocation via capacity block mask
This commit wires up the CBQRI capacity controllers into resctrl as
RDT_RESOURCE_L2 and RDT_RESOURCE_L3 schemata. It treats mismatched
capabilities at the same cache level as a fatal error and lazily creates
domains in the cpuhp online callback.
> diff --git a/drivers/resctrl/cbqri_resctrl.c b/drivers/resctrl/cbqri_resctrl.c
> new file mode 100644
> index 0000000000000..2f31baff032b6
> --- /dev/null
> +++ b/drivers/resctrl/cbqri_resctrl.c
[ ... ]
> +static int cbqri_attach_cpu_to_all_ctrls(unsigned int cpu)
> +{
> + struct cbqri_controller *ctrl;
> + int err = 0;
> +
> + lockdep_assert_held(&cbqri_domain_list_lock);
> +
> + list_for_each_entry(ctrl, &cbqri_controllers, list) {
[Severity: High]
Is it safe to iterate the global cbqri_controllers list without holding
cbqri_controllers_lock?
If a capacity controller is dynamically added at runtime (e.g., via a device
tree overlay instantiating the platform device), its probe function can acquire
cbqri_controllers_lock and mutate the cbqri_controllers list.
Concurrently, if a CPU is hotplugged, the cpuhp online callback calls
cbqri_resctrl_online_cpu() which invokes this function. Traversing the list
here while holding only cbqri_domain_list_lock could lead to list corruption,
resulting in an infinite loop or NULL pointer dereference.
> + if (ctrl->type != CBQRI_CONTROLLER_TYPE_CAPACITY)
> + continue;
> + if (!cpumask_test_cpu(cpu, &ctrl->cache.cpu_mask))
> + continue;
> + if (!ctrl->alloc_capable)
> + continue;
> +
> + err = cbqri_attach_cpu_to_cap_ctrl(ctrl, cpu);
> + if (err) {
> + cbqri_detach_cpu_from_all_ctrls(cpu);
> + break;
> + }
> + }
> +
> + return err;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-dfustini-atl-sc-cbqri-dt-v2-0-2f8049fd902b@kernel.org?part=5
next prev parent reply other threads:[~2026-06-25 1:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 1:38 [PATCH v2 0/8] riscv: Add Ssqosid and initial CBQRI resctrl support Drew Fustini
2026-06-25 1:38 ` [PATCH v2 1/8] dt-bindings: riscv: Add Ssqosid extension description Drew Fustini
2026-06-25 1:38 ` [PATCH v2 2/8] riscv: Detect the Ssqosid extension Drew Fustini
2026-06-25 1:38 ` [PATCH v2 3/8] riscv: Add support for srmcfg CSR from " Drew Fustini
2026-06-25 1:50 ` sashiko-bot
2026-06-25 1:38 ` [PATCH v2 4/8] riscv_cbqri: Add capacity controller probe and allocation device ops Drew Fustini
2026-06-25 1:38 ` [PATCH v2 5/8] riscv_cbqri: resctrl: Add cache allocation via capacity block mask Drew Fustini
2026-06-25 1:53 ` sashiko-bot [this message]
2026-06-25 1:38 ` [PATCH v2 6/8] riscv: Enable resctrl filesystem for Ssqosid Drew Fustini
2026-06-25 1:38 ` [PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding Drew Fustini
2026-06-25 1:38 ` [PATCH v2 8/8] riscv_cbqri: Add CBQRI cache capacity-allocation platform driver Drew Fustini
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=20260625015355.B997D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fustini@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox