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.
