From: sashiko-bot@kernel.org
To: "Ehab Ababneh" <ehab.ababneh@intel.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 09/17] platform/x86/intel/ifs: Select CPUs from topology_cluster_cpumask() for simultaneous IFS tests
Date: Mon, 26 Oct 2026 18:47:06 +0000 [thread overview]
Message-ID: <sashiko-outbox-185638@kernel.org> (raw)
In-Reply-To: <20261026183820.129459-10-ehab.ababneh@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] platform/x86/intel/ifs: build_cpugroup_mask() called before cpu_online() check
--
commit 206d196a9743b86ac3f7ca97505586f73d04016c
Author: Jithu Joseph <jithu.joseph@intel.com>
platform/x86/intel/ifs: Select CPUs from topology_cluster_cpumask() for simultaneous IFS tests
This commit updates the intel_ifs driver to record the group of CPUs
tested simultaneously in ifsd->grp_cpumask using topology_cluster_cpumask()
and stop_cluster_cpuslocked() when ifsd->all_lp_join is set.
> diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c
> index c6a4d6dcccf1f..09e7a81e92204 100644
> --- a/drivers/platform/x86/intel/ifs/runtest.c
> +++ b/drivers/platform/x86/intel/ifs/runtest.c
[ ... ]
> @@ -398,6 +407,24 @@ static void ifs_array_test_gen1(int cpu, struct device *dev)
> ifsd->status = SCAN_TEST_PASS;
> }
>
> +static void build_cpugroup_mask(struct device *dev, int cpu)
> +{
> + struct ifs_data *ifsd = ifs_get_data(dev);
> +
> + cpumask_clear(&ifsd->grp_cpumask);
> +
> + /*
> + * Some CPUs, such as Sierra Forest and Clearwater Forest, have multiple cores
> + * sharing the same SCAN test engine, but they don't require a rendezvous.
> + */
> + if (!ifsd->all_lp_join) {
> + cpumask_set_cpu(cpu, &ifsd->grp_cpumask);
> + return;
> + }
> +
> + cpumask_copy(&ifsd->grp_cpumask, topology_cluster_cpumask(cpu));
> +}
> +
> /*
> * Initiate per core test. It wakes up work queue threads on the target CPU and
> * its sibling CPU. Once all sibling threads wake up, the scan test gets executed and
> @@ -411,6 +438,7 @@ int do_core_test(int cpu, struct device *dev)
>
> /* Prevent CPUs from being taken offline during the scan test */
> cpus_read_lock();
> + build_cpugroup_mask(dev, cpu);
>
> if (!cpu_online(cpu)) {
> dev_info(dev, "cannot test on the offline CPU %d\n", cpu);
[Severity: High]
Should build_cpugroup_mask(dev, cpu) be called after the !cpu_online(cpu)
check in do_core_test() rather than before it?
In drivers/platform/x86/intel/ifs/sysfs.c, run_test_store() only checks
that cpu < nr_cpu_ids before invoking do_core_test(cpu, dev):
drivers/platform/x86/intel/ifs/sysfs.c:run_test_store() {
...
rc = kstrtouint(buf, 0, &cpu);
if (rc < 0 || cpu >= nr_cpu_ids)
return -EINVAL;
rc = mutex_lock_interruptible(&ifs_sem);
if (rc)
return rc;
rc = do_core_test(cpu, dev);
...
}
However, in arch/x86/kernel/smpboot.c, smp_prepare_cpus_common() only
allocates per_cpu(cpu_l2c_shared_map, cpu) for CPUs in cpu_possible_mask:
arch/x86/kernel/smpboot.c:smp_prepare_cpus_common() {
...
for_each_possible_cpu(cpu) {
node = cpu_to_node(cpu);
...
zalloc_cpumask_var_node(&per_cpu(cpu_l2c_shared_map, cpu), GFP_KERNEL, node);
}
}
If userspace writes a CPU index that is less than nr_cpu_ids but not in
cpu_possible_mask (for example when CONFIG_FORCE_NR_CPUS=y or when
cpu_possible_mask is sparse), calling build_cpugroup_mask() before
checking cpu_online(cpu) will invoke:
build_cpugroup_mask()
topology_cluster_cpumask(cpu)
cpu_clustergroup_mask(cpu)
cpu_l2c_shared_mask(cpu)
per_cpu(cpu_l2c_shared_map, cpu)
Can this access an uninitialized per-CPU offset and dereference a NULL
cpumask_var_t pointer under CONFIG_CPUMASK_OFFSTACK=y (or set a
non-possible CPU bit in ifsd->grp_cpumask when ifsd->all_lp_join is false,
which later sysfs readers in this series pass to
per_cpu_ptr(ifsd->result_ptr, lcpu))?
Additionally, when a valid possible CPU is offline, remove_siblinginfo()
clears cpu_l2c_shared_mask(cpu). If userspace attempts to run a test on an
offline CPU and do_core_test() returns -EINVAL, won't calling
build_cpugroup_mask() beforehand overwrite ifsd->grp_cpumask with an empty
mask (when ifsd->all_lp_join is true) or with the untested offline CPU
(when ifsd->all_lp_join is false), clobbering the previous test's CPU
group state exposed by cpus_ran_list, status_list, details_list, and
addnl_details_list added in the subsequent patches?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261026183820.129459-1-ehab.ababneh@intel.com?part=9
next prev parent reply other threads:[~2026-10-26 18:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 18:38 [PATCH 00/17] platform/x86/intel/ifs: Support group-based In-Field Scan and Diamond Rapids Ehab Ababneh
2026-10-26 18:38 ` [PATCH 01/17] platform/x86/intel/ifs: Revert SBAF feature Ehab Ababneh
2026-10-26 18:38 ` [PATCH 02/17] platform/x86/intel/ifs: Fix IFS sysfs interfaces in the comments Ehab Ababneh
2026-10-26 18:38 ` [PATCH 03/17] platform/x86/intel/ifs: Clarify In-Field Scan MSR bit macro definitions Ehab Ababneh
2026-10-26 18:38 ` [PATCH 04/17] platform/x86/intel/ifs: Use u64 to define the bits of IFS MSR registers Ehab Ababneh
2026-10-26 18:38 ` [PATCH 05/17] platform/x86/intel/ifs: Early return on the IFS image hash/chunk error Ehab Ababneh
2026-10-26 18:38 ` [PATCH 06/17] platform/x86/intel/ifs: Refactor Array BIST function interface Ehab Ababneh
2026-10-26 18:38 ` [PATCH 07/17] stop_machine: Add stop_cluster_cpuslocked() for per-cluster operations Ehab Ababneh
2026-10-26 18:38 ` [PATCH 08/17] platform/x86/intel/ifs: Enumerate the bit to determine if CPUs need to join for IFS tests Ehab Ababneh
2026-10-26 18:38 ` [PATCH 09/17] platform/x86/intel/ifs: Select CPUs from topology_cluster_cpumask() for simultaneous " Ehab Ababneh
2026-10-26 18:47 ` sashiko-bot [this message]
2026-10-26 18:38 ` [PATCH 10/17] platform/x86/intel/ifs: Validate TID_BIT_SHIFT matches topology_cluster_cpumask() Ehab Ababneh
2026-10-26 18:49 ` sashiko-bot
2026-10-26 18:38 ` [PATCH 11/17] platform/x86/intel/ifs: Track and report scan results on a per-CPU basis Ehab Ababneh
2026-10-26 18:54 ` sashiko-bot
2026-10-26 18:38 ` [PATCH 12/17] platform/x86/intel/ifs: Add new sysfs interfaces {status, details, cpus_ran}_list Ehab Ababneh
2026-10-26 18:49 ` sashiko-bot
2026-10-26 18:38 ` [PATCH 13/17] platform/x86/intel/ifs: Add additional details sysfs interface Ehab Ababneh
2026-10-26 18:38 ` [PATCH 14/17] platform/x86/intel/ifs: Add Intel Diamond Rapids server support Ehab Ababneh
2026-10-26 18:38 ` [PATCH 15/17] platform/x86/intel/ifs: Remove limit on number of batch files Ehab Ababneh
2026-10-26 18:38 ` [PATCH 16/17] platform/x86/intel/ifs: Update IFS documentation Ehab Ababneh
2026-10-26 18:58 ` sashiko-bot
2026-10-26 18:38 ` [PATCH 17/17] Documentation/ABI: Update IFS ABI doc Ehab Ababneh
2026-10-26 18:54 ` sashiko-bot
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=sashiko-outbox-185638@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ehab.ababneh@intel.com \
--cc=linux-trace-kernel@vger.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