linux-kernel - Re: [PATCH] iommu: __iommu_attach_group: check for non-NULL blocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1f920cc2-625c-48af-a6d0-a505980fbeaa@kernel.org>
Date: Tue, 7 Oct 2025 11:38:08 +0200
From: Hans Verkuil <hverkuil+cisco@...nel.org>
To: iommu@...ts.linux.dev
Cc: Linux Kernel <linux-kernel@...r.kernel.org>,
 Linux Media Mailing List <linux-media@...r.kernel.org>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Jason Gunthorpe <jgg@...dia.com>, Robin Murphy <robin.murphy@....com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: Re: [PATCH] iommu: __iommu_attach_group: check for non-NULL
 blocking_domain

Hi all,

On 29/09/2025 10:23, Hans Verkuil wrote:
> Loading the omap3isp driver fails in __iommu_attach_group:
> group->blocking_domain is NULL, and so the check
> group->domain != group->blocking_domain is always true and it
> returns -EBUSY.
> 
> Only return -EBUSY if group->blocking_domain is non-NULL.
> 
> Signed-off-by: Hans Verkuil <hverkuil+cisco@...nel.org>
> Fixes: 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must always assign a domain")
> ---

So just ignore this patch :-)

Today I dropped this patch from my branch, and retested on my Beagle xM and it all
worked fine.

I suspect that it might be related to the fact that I started testing with the Beagle
board (so not the xM variant), and I hit the issue there. But the Beagle board doesn't
have the connector for the camera, so later I switched to the xM variant. But I probably
never tried running it on the xM without that iommu patch until today.

In two weeks time I have access to my Beagle board again and I'll experiment a bit
to see if my theory is correct.

Apologies for all the noise.

Regards,

	Hans

> Since I am unfamiliar with the iommu core code, I am uncertain whether I am
> just papering over a bug elsewhere, or whether this is really the correct solution.
> 
> The omap3isp code in question is here:
> 
> drivers/media/platform/ti/omap3isp/isp.c, function isp_attach_iommu().
> 
> This omap3isp code predates the addition of blocking_domain and it used to work
> before that feature was added.
> 
> I've tested this patch with my Beagle XM board.
> 
> If this patch is addressing the issue in the wrong place, then advise
> on what the correct solution is would be very much appreciated!
> 
> I have a bunch of media omap3isp cleanup patches pending, but there is no point in
> posting those until this issue is resolved.
> 
> Regards,
> 
> 	Hans
> ---
>  drivers/iommu/iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 060ebe330ee1..0ab1671ee850 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2220,7 +2220,7 @@ static int __iommu_attach_group(struct iommu_domain *domain,
>  	struct device *dev;
> 
>  	if (group->domain && group->domain != group->default_domain &&
> -	    group->domain != group->blocking_domain)
> +	    group->blocking_domain && group->domain != group->blocking_domain)
>  		return -EBUSY;
> 
>  	dev = iommu_group_first_dev(group);