Re: [PATCH v14 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure

[Robin Murphy <robin.murphy@arm.com>]

On 01/08/2024 4:29 pm, niliqiang wrote:
>> +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
>> +				  struct arm_smmu_master *master)
>> +{
>> +	int i;
>> +	int ret = 0;
>> +	struct arm_smmu_stream *new_stream, *cur_stream;
>> +	struct rb_node **new_node, *parent_node = NULL;
>> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
>> +
>> +	master->streams = kcalloc(fwspec->num_ids, sizeof(*master->streams),
>> +				  GFP_KERNEL);
>> +	if (!master->streams)
>> +		return -ENOMEM;
>> +	master->num_streams = fwspec->num_ids;
>> +
>> +	mutex_lock(&smmu->streams_mutex);
>> +	for (i = 0; i < fwspec->num_ids; i++) {
> 
> Hi all experts,
> 
> Recently, I have been debugging the smmuv3 code in the Linux kernel,
> and I have some questions regarding the `mutex_lock(&smmu->streams_mutex)`
> statement in the `arm_smmu_insert_master` function.
> I would like to understand why streams_mutex is being locked here.

Because the "streams" rbtree is being modified, so it would be pretty 
bad if another thread tried to walk or modify it concurrently. I'd hope 
that was obvious from the code everywhere "streams" and "streams_mutex" 
are referenced.

> Is it to handle different types of PF under a single EP, each with its own device ID?

It is expected that a single SMMU instance is highly likely to have more 
than one device behind it, and therefore more than one StreamID to keep 
track of.

Thanks,
Robin.