[PATCH RFC v5 2/6] iommu/arm-smmu-v3: Allocate streams individually

[Nicolin Chen]

On Thu, Oct 08, 2026 at 02:21:43PM +0100, Robin Murphy wrote:
> On 08/10/2026 12:17 am, Nicolin Chen wrote:
> > On Tue, Oct 06, 2026 at 08:19:08PM +0800, Peng Fan (OSS) wrote:
> > > diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
> > > index 6644075c1431e..bc62a3d5a63f9 100644
> > > --- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
> > > +++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
> > > @@ -1257,7 +1257,7 @@ static int tegra241_vintf_init_vsid(struct iommufd_vdevice *vdev)
> > >   	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > >   	struct tegra241_vintf *vintf = viommu_to_vintf(vdev->viommu);
> > >   	struct tegra241_vintf_sid *vsid = vdev_to_vsid(vdev);
> > > -	struct arm_smmu_stream *stream = &master->streams[0];
> > > +	struct arm_smmu_stream *stream = master->streams[0];
> > 
> > Sashiko raised a concern of an out-of-bounds pointer dereference.
> > 
> > Though it's practically not possible, probably it would be safer
> > to move this behind the check:
> > 
> > 	if (master->num_streams != 1)
> > 		return -EOPNOTSUPP;
> 
> The IORT path unconditionally adds 1 ID via acpi_iommu_fwspec_init(), so
> num_streams==0 could only potentially happen with DT if a fwspec was parsed
> using #iommu-cells==0, except arm_smmu_device_dt_probe() would refuse to
> probe the entire SMMU if that was anything other than 1, so no, this
> definitely cannot ever be out of bounds.

Yea, it's unreachable. So, either way is fine.

The num_streams guard is already there: doing a dereference after
the guard is a common practice anyway. And that drops the Sashiko
false positive.

Nicolin