From: "Chen, Zide" <zide.chen@intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 4/6] perf/x86/intel/uncore: Move die_to_cpu() to uncore.c
Date: Wed, 13 May 2026 11:11:18 -0700 [thread overview]
Message-ID: <aefcf357-e0d8-46af-841d-be3e7742374b@intel.com> (raw)
In-Reply-To: <20260513025843.939F7C2BCB0@smtp.kernel.org>
On 5/12/2026 7:58 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Recursive `cpus_read_lock()` acquisition leads to deadlock when used by the planned initialization callback.
> --
>
> commit d8b9d983f61a73e17f268ae570b5186a67f1a6ae
> Author: Zide Chen <zide.chen@intel.com>
>
> perf/x86/intel/uncore: Move die_to_cpu() to uncore.c
>
> This commit moves die_to_cpu() into uncore.c and renames it to
> uncore_die_to_cpu(). This change prepares the function to be reused by a
> planned MSR global initialization callback.
>
>> diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
>> index e9cc1ba921c5e..2bbe4cc1df3e2 100644
>> --- a/arch/x86/events/intel/uncore.c
>> +++ b/arch/x86/events/intel/uncore.c
> [ ... ]
>> @@ -83,6 +83,25 @@ int uncore_device_to_die(struct pci_dev *dev)
>> return -1;
>> }
>>
>> +int uncore_die_to_cpu(int die)
>> +{
>> + int res = 0, cpu;
>> +
>> + /*
>> + * Using cpus_read_lock() to ensure cpu is not going down between
>> + * looking at cpu_online_mask.
>> + */
>> + cpus_read_lock();
>
> Will the planned MSR global initialization callback already hold
> cpus_read_lock() when it calls this function?
>
> If the initialization path (such as uncore_discovery_msr() calling into
> __parse_discovery_table()) already holds the lock, does acquiring it a
> second time here risk a lockdep warning or a deadlock?
>
> Since cpus_read_lock() is backed by a percpu rwsem, a second read lock by
> the same thread can block if a writer (like CPU hotplug) is pending. Does
> this API need an unlocked variant for initialization paths, or should it
> rely on the caller to manage the lock entirely?
Yes, you are right. Seems the best option would be to remove the lock
from uncore_die_to_cpu(), and rely on callers to manage the lock.
>
>> + for_each_online_cpu(cpu) {
>> + if (topology_logical_die_id(cpu) == die) {
>> + res = cpu;
>> + break;
>> + }
>> + }
>> + cpus_read_unlock();
>> + return res;
>> +}
>
next prev parent reply other threads:[~2026-05-13 18:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 23:05 [PATCH 0/6] perf/x86/intel/uncore: Bug fixes and cleanups Zide Chen
2026-05-11 23:05 ` [PATCH 1/6] perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems Zide Chen
2026-05-13 1:49 ` sashiko-bot
2026-05-13 18:35 ` Chen, Zide
2026-05-11 23:05 ` [PATCH 2/6] perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery Zide Chen
2026-05-12 9:27 ` Mi, Dapeng
2026-05-12 17:35 ` Chen, Zide
2026-05-13 0:31 ` Mi, Dapeng
2026-05-11 23:05 ` [PATCH 3/6] perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box() Zide Chen
2026-05-13 2:33 ` sashiko-bot
2026-05-13 17:58 ` Chen, Zide
2026-05-11 23:05 ` [PATCH 4/6] perf/x86/intel/uncore: Move die_to_cpu() to uncore.c Zide Chen
2026-05-13 2:58 ` sashiko-bot
2026-05-13 18:11 ` Chen, Zide [this message]
2026-05-11 23:05 ` [PATCH 5/6] perf/x86/intel/uncore: Fix uncore_die_to_cpu() for offline dies Zide Chen
2026-05-11 23:05 ` [PATCH 6/6] perf/x86/intel/uncore: Implement global init callback for GNR uncore Zide Chen
2026-05-13 4:25 ` sashiko-bot
2026-05-13 18:26 ` Chen, Zide
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=aefcf357-e0d8-46af-841d-be3e7742374b@intel.com \
--to=zide.chen@intel.com \
--cc=linux-perf-users@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