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

Robin Murphy
2024-08-02T12:02:40Z

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.