Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Shuai Xue <xueshuai@linux.alibaba.com>
To: yunhui cui <cuiyunhui@bytedance.com>
Cc: renyu.zj@linux.alibaba.com, will@kernel.org,
	mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH] perf/dwc_pcie: fix duplicate pci_dev devices
Date: Fri, 24 Jan 2025 14:48:30 +0800	[thread overview]
Message-ID: <31e00081-8695-4ca6-a1ef-af5a007a7565@linux.alibaba.com> (raw)
In-Reply-To: <CAEEQ3wmDej9bbPUmkx-ZrD4FG9Z7gTHMeCrVszx64g90O0RyiQ@mail.gmail.com>



在 2025/1/24 10:56, yunhui cui 写道:
> Hi Shuai,
> 
> On Thu, Jan 23, 2025 at 5:50 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote:
>>
>>
>>
>> 在 2025/1/23 15:48, Yunhui Cui 写道:
>>> During platform_device_register, wrongly using struct device
>>> pci_dev as platform_data caused a kmemdup copy of pci_dev. Worse
>>> still, accessing the duplicated device leads to list corruption as its
>>> mutex content (e.g., list, magic) remains the same as the original.
>>>
>>> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
>>> ---
>>>    drivers/perf/dwc_pcie_pmu.c | 25 ++++++++++++++++++-------
>>>    1 file changed, 18 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c
>>> index cccecae9823f..8b208f287a1f 100644
>>> --- a/drivers/perf/dwc_pcie_pmu.c
>>> +++ b/drivers/perf/dwc_pcie_pmu.c
>>> @@ -565,9 +565,7 @@ static int dwc_pcie_register_dev(struct pci_dev *pdev)
>>>        u32 sbdf;
>>>
>>>        sbdf = (pci_domain_nr(pdev->bus) << 16) | PCI_DEVID(pdev->bus->number, pdev->devfn);
>>> -     plat_dev = platform_device_register_data(NULL, "dwc_pcie_pmu", sbdf,
>>> -                                              pdev, sizeof(*pdev));
>>> -
>>> +     plat_dev = platform_device_register_simple("platform_dwc_pcie", sbdf, NULL, 0);
>>>        if (IS_ERR(plat_dev))
>>>                return PTR_ERR(plat_dev);
>>>
>>> @@ -614,19 +612,32 @@ static struct notifier_block dwc_pcie_pmu_nb = {
>>>
>>>    static int dwc_pcie_pmu_probe(struct platform_device *plat_dev)
>>>    {
>>> -     struct pci_dev *pdev = plat_dev->dev.platform_data;
>>> +     struct pci_dev *pdev = NULL;
>>>        struct dwc_pcie_pmu *pcie_pmu;
>>> +     bool found = false;
>>>        char *name;
>>>        u32 sbdf;
>>>        u16 vsec;
>>>        int ret;
>>>
>>> +     for_each_pci_dev(pdev) {
>>> +             sbdf = (pci_domain_nr(pdev->bus) << 16) | PCI_DEVID(pdev->bus->number, pdev->devfn);
>>> +             if (sbdf == plat_dev->id) {
>>> +                     found = true;
>>> +                     break;
>>> +             }
>>> +     }
>>> +     if (!found) {
>>> +             pr_err("The plat_dev->id does not match the sbdf");
>>> +             return -ENODEV;
>>> +     }
>>> +
>>
>> How about using pci_get_domain_bus_and_slot() to find pci_dev?
> It's not necessary. pci_get_domain_bus_and_slot also invokes
> for_each_pci_dev, and it further requires splitting the sbdf.

Compose sbdf from domain, bus number, and devfn is almost essentially
corresponding opposite operation. And I think we should grab a reference
count of pdev and handle it properly.

Personally speaking, I prefer pci_get_domain_bus_and_slot() because it is
simple and robust.

> 
>>
>>>        vsec = dwc_pcie_des_cap(pdev);
>>>        if (!vsec)
>>>                return -ENODEV;
>>>
>>>        sbdf = plat_dev->id;
>>> -     name = devm_kasprintf(&plat_dev->dev, GFP_KERNEL, "dwc_rootport_%x", sbdf);
>>> +     name = devm_kasprintf(&plat_dev->dev, GFP_KERNEL, "dwc_rootport_%d_pmu", sbdf);
>>
>> A new name will break previous user tools.
> This name isn't suitable. It can't clearly show which is the PMU
> device. Userspace tools don't have binding relationships, like perf.
> Tools must traverse PMU devices before use.

The device is under /sys/bus/event_source/ which indates it is PMU device.
As far as I know, most of PMU devices do not endup with a '_pmu' prefix.

Thanks.

Shuai



  reply	other threads:[~2025-01-24  6:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23  7:48 [PATCH] perf/dwc_pcie: fix duplicate pci_dev devices Yunhui Cui
2025-01-23  9:49 ` Shuai Xue
2025-01-24  2:56   ` [External] " yunhui cui
2025-01-24  6:48     ` Shuai Xue [this message]
2025-01-24  9:11       ` yunhui cui
2025-01-24 12:29         ` Will Deacon
2025-01-26  1:54           ` yunhui cui
2025-01-27 16:51             ` Will Deacon
2025-02-01  9:51               ` yunhui cui
2025-02-04 12:31                 ` Will Deacon
2025-02-05  1:45                   ` yunhui cui

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=31e00081-8695-4ca6-a1ef-af5a007a7565@linux.alibaba.com \
    --to=xueshuai@linux.alibaba.com \
    --cc=cuiyunhui@bytedance.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=renyu.zj@linux.alibaba.com \
    --cc=will@kernel.org \
    /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