Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vikash Garodia" <vikash.garodia@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org,
	media-ci@linuxtv.org
Subject: Re: [PATCH 07/22] arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris
Date: Fri, 07 Aug 2026 08:44:54 +0000	[thread overview]
Message-ID: <20260807084455.452D11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807-iris_iova_600mb_fix-v1-7-3996f67e33f9@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] If `of_translate_dma_region()` fails during IOVA reservation parsing, it returns NULL, which causes a subsequent NULL pointer dereference on the next loop iteration.
- [Medium] The device node reference obtained via `of_find_node_by_phandle()` is never released, leading to a memory leak.
--

--- Patch [7]: [PATCH 07/22] arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris ---
commit 5bb5ca70fa7d2aa5a3d66cdd7f006042161ce0dc
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris

This patch reserves an IOVA range for the Iris VPU to prevent unhandled
SMMU page faults when DMA accesses that range from other stream IDs. It
achieves this by adding a reserved-memory IOVA reservation node and
referencing it from the Iris node.

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index fbcfd3883bbb4..1c624683d0033 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -669,6 +669,17 @@ reserved-region@aeb00000 {
>  			reg = <0 0xaeb00000 0 0x16600000>;
>  			no-map;
>  		};
> +
> +		/*
> +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
> +		 * primarily for non-pixel buffers using different Stream IDs.
> +		 * DMA into that range triggers unhandled SMMU faults and
> +		 * spontaneous reboots, so reserve it to keep IOMMU
> +		 * allocations above this boundary.
> +		 */
> +		iris_iova: iris-iova {
> +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;

[Severity: Medium]
This is a pre-existing issue, but does of_iommu_get_resv_regions() leak the
device node reference when processing the iommu-addresses property?

When parsing these nodes, the reference is acquired via
of_find_node_by_phandle():

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
			np = of_find_node_by_phandle(phandle);
    ...
}

But it looks like of_node_put(np) is never called within the loop or the
function, which would result in a leak on every element in the property.

[Severity: High]
This is a pre-existing issue, but is there a risk of a NULL pointer
dereference here if of_translate_dma_region() fails?

If the translation fails (for example, due to an invalid DMA parent),
of_translate_dma_region() returns NULL:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
				maps = of_translate_dma_region(np, maps, &iova, &length);
				if (length == 0) {
					dev_warn(dev, "Cannot reserve IOVA region of 0 size\n");
					continue;
				}
    ...
}

Since maps is updated to NULL, the loop condition (maps < end) still
evaluates to true. On the next iteration, be32_to_cpup(maps++) would
unconditionally dereference the NULL pointer:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
    ...
}

> +		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=7

  reply	other threads:[~2026-08-07  8:44 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5BXSXMNl656WiJPJAMmHvb3I2NzYMshRZuGuub3CxEXvdCUlIDKYbnv5jUq-pa6P1NibBLkO3njnKGxi7Al3jQ==@protonmail.internalid>
2026-08-07  8:24 ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Vikash Garodia
2026-08-07  8:24   ` [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region Vikash Garodia
2026-08-07  8:49     ` sashiko-bot
2026-08-07  8:51       ` Vikash Garodia
2026-08-07  8:24   ` [PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: " Vikash Garodia
2026-08-07  8:40     ` sashiko-bot
2026-08-07  9:01     ` Dmitry Baryshkov
2026-08-07  8:24   ` [PATCH 03/22] dt-bindings: media: qcom,sc7180-venus: " Vikash Garodia
2026-08-07  8:24   ` [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris Vikash Garodia
2026-08-07  8:45     ` sashiko-bot
2026-08-07  9:03     ` Dmitry Baryshkov
2026-08-07  9:26       ` Vikash Garodia
2026-08-07 10:00         ` Dmitry Baryshkov
2026-08-07 10:22           ` Vikash Garodia
2026-08-07 13:18             ` Bryan O'Donoghue
2026-08-07 16:24       ` Rob Herring
2026-08-08  4:37         ` Vishnu Reddy
2026-08-07  8:24   ` [PATCH 05/22] arm64: dts: qcom: lemans: " Vikash Garodia
2026-08-07  8:44     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 06/22] arm64: dts: qcom: monaco: " Vikash Garodia
2026-08-07  8:47     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 07/22] arm64: dts: qcom: sc8280xp: " Vikash Garodia
2026-08-07  8:44     ` sashiko-bot [this message]
2026-08-07  8:24   ` [PATCH 08/22] arm64: dts: qcom: sm8350: " Vikash Garodia
2026-08-07  8:50     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 09/22] arm64: dts: qcom: sm8550: " Vikash Garodia
2026-08-07  8:46     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 10/22] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-08-07  8:42     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 11/22] arm64: dts: qcom: sm8750: " Vikash Garodia
2026-08-07  8:54     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 12/22] arm64: dts: qcom: agatti: Reserve low IOVA range for Venus Vikash Garodia
2026-08-07  8:57     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 13/22] arm64: dts: qcom: kodiak: " Vikash Garodia
2026-08-07  8:54     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 14/22] arm64: dts: qcom: msm8916: " Vikash Garodia
2026-08-07  8:58     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 15/22] arm64: dts: qcom: msm8996: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 16/22] arm64: dts: qcom: msm8998: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 17/22] arm64: dts: qcom: sc7180: " Vikash Garodia
2026-08-07  8:59     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 18/22] arm64: dts: qcom: sdm630: " Vikash Garodia
2026-08-07  9:00     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 19/22] arm64: dts: qcom: sdm845: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 20/22] arm64: dts: qcom: sm6115: " Vikash Garodia
2026-08-07  9:05     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 21/22] arm64: dts: qcom: sm8250: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 22/22] arm64: dts: qcom: talos: " Vikash Garodia
2026-08-07  9:08     ` sashiko-bot
2026-08-07  8:51   ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Bryan O'Donoghue
2026-08-07  8:59   ` Dmitry Baryshkov
2026-08-07  9:05     ` Vikash Garodia
2026-08-07 10:01       ` Dmitry Baryshkov

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=20260807084455.452D11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vikash.garodia@oss.qualcomm.com \
    /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