From: sashiko-bot@kernel.org
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
Date: Wed, 08 Apr 2026 08:46:05 +0000 [thread overview]
Message-ID: <20260408084606.025DDC19424@smtp.kernel.org> (raw)
In-Reply-To: <20260408-smmu-perf-v1-3-d75dac96e828@nxp.com>
Sashiko AI review found 1 potential issue(s):
- [High] Incorrect error checking for `devm_ioremap()` return value leads to potential NULL pointer dereference.
--
commit 9648b36d883f07ba004ca17984ae1bfebc0a29df
Author: Peng Fan <peng.fan@nxp.com>
perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
This commit maps the PMCG memory resources directly using devm_ioremap
to avoid double-requesting the SMMU MMIO space that is already requested
by the arm-smmu-v3 driver.
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index 621f02a7f43be..1c9585ef26183 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
[ ... ]
> @@ -877,7 +877,16 @@ static int smmu_pmu_probe(struct platform_device *pdev)
> .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> };
>
> - smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res_0);
> + res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res_0)
> + return dev_err_probe(dev, -ENOENT, "missing PMCG page 0 MMIO resource\n");
> +
> + /*
> + * PMCG registers might be a sub-region of the parent SMMU MMIO window,
> + * which is already requested by the SMMU driver. Do not call
> + * devm_ioremap_resource() here to avoid double-requesting the region.
> + */
> + smmu_pmu->reg_base = devm_ioremap(dev, res_0->start, resource_size(res_0));
> if (IS_ERR(smmu_pmu->reg_base))
> return PTR_ERR(smmu_pmu->reg_base);
Since devm_ioremap returns NULL on failure instead of an ERR_PTR, will this
IS_ERR check fail to catch unsuccessful mappings?
If devm_ioremap returns NULL, IS_ERR(NULL) evaluates to false, which would
allow the code to proceed and potentially dereference a NULL pointer shortly
after when reading cfgr.
Would it be better to check for !smmu_pmu->reg_base here and return
-ENOMEM?
>
> @@ -885,7 +894,11 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>
> /* Determine if page 1 is present */
> if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
> - smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
> + res_1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res_1)
> + return dev_err_probe(dev, -ENOENT, "missing PMCG page 1 MMIO resource\n");
> +
> + smmu_pmu->reloc_base = devm_ioremap(dev, res_1->start, resource_size(res_1));
> if (IS_ERR(smmu_pmu->reloc_base))
> return PTR_ERR(smmu_pmu->reloc_base);
This appears to have the same issue. Does this IS_ERR check also need to be
updated to handle a NULL return from devm_ioremap?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260408-smmu-perf-v1-0-d75dac96e828@nxp.com?part=3
next prev parent reply other threads:[~2026-04-08 8:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 7:51 [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping Peng Fan (OSS)
2026-04-08 7:51 ` [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes Peng Fan (OSS)
2026-04-09 8:10 ` Krzysztof Kozlowski
2026-04-09 12:45 ` Peng Fan
2026-04-08 7:51 ` [PATCH 2/3] iommu/arm-smmu-v3: Populate PMU child devices from Devicetree Peng Fan (OSS)
2026-04-08 8:39 ` sashiko-bot
2026-04-08 7:51 ` [PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG Peng Fan (OSS)
2026-04-08 8:46 ` sashiko-bot [this message]
2026-04-08 11:15 ` [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping Robin Murphy
2026-04-08 13:47 ` Peng Fan
2026-04-10 12:07 ` Robin Murphy
2026-04-14 7:47 ` Peng Fan
2026-04-14 9:32 ` Robin Murphy
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=20260408084606.025DDC19424@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=peng.fan@oss.nxp.com \
--cc=sashiko@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.