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 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.