Re: [PATCH 1/2] iommu/arm-smmu-v3: Replace sort_nonatomic() with sort()

Pranjal Shrivastava <[email protected]> Mon, 3 Aug 2026 13:37:16 +0000
Newsgroups dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, Aug 03, 2026 at 01:35:52PM +0100, Robin Murphy wrote:
> On 02/08/2026 6:45 pm, Nicolin Chen wrote:
> > On Sun, Aug 02, 2026 at 10:23:48AM +0100, Will Deacon wrote:
> > > On Thu, Jul 30, 2026 at 06:12:15PM +0000, Kuan-Wei Chiu wrote:
> > > > @@ -4047,9 +4047,9 @@ static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > > >   	}
> > > >   	/* Put the ids into order for sorted to_merge/to_unref arrays */
> > > > -	sort_nonatomic(master->streams, master->num_streams,
> > > > -		       sizeof(master->streams[0]), arm_smmu_stream_id_cmp,
> > > > -		       NULL);
> > > > +	sort(master->streams, master->num_streams,
> > > > +	     sizeof(master->streams[0]), arm_smmu_stream_id_cmp,
> > > > +	     NULL);
> > > 
> > > Makes sense to me. Nicolin, did you choose the nonatomic version
> > > specifically?
> > 
> > It's probably rare to have a large multi-stream array, so I think
> > sort() would be fine.
> 
> Yeah, probably 99% of the time the size of this array will be 1. An
> exceptional value of "large" might be something like 64 for a massive
> (non-PCI) DMA engine with separate read and write IDs per channel for no
> good reason.
> 
> If and when someone ever were to report RCU stalls here then we can first
> ask them what the heck their client device is... and unless and until then I
> wouldn't think it's worth worrying about.
> 

+1. Agreed, it should be fine to use sort() here..

> Thanks,
> Robin.
> 

Thanks,
Praan