From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A442CC52D6D for ; Fri, 2 Aug 2024 12:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rdQfvBCxjkYDV7WZfzbk8dmekJjLtcamb/AYrtNjaiI=; b=NI9U5uN6pULdNJu98bkUw1sAQU PQ5TgT8XAjDaD6mkA2R9h06WXHyol/aDGbbdDIyz9Dnx6+fhS9MQ6ATKHFip1PC56MrNRUGyMCkVW yzqru3deOxW8s2e/yvNnsI1sZQZbXR5ZHOd/3sVGXO7uig2hSAqEYuK6B7cG6cc2XxrGaD3U51tuc qkxzC0/+jk1uRvmXXZcFGCNXgemGwnkIIHPAS2iIT/Sllp7WHRaVU2LcU/U8cC1nvUg9dtFgF8cdk BvffCd1DaXjpRfSrC9CdPRDSCTRo9w46joMrzURcUlH8dFAtzi3NWq3HjbatCx0P18zfYHsvdRj4g 1vp8MdDA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZqzG-00000008kxJ-02Ho; Fri, 02 Aug 2024 12:02:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZqyl-00000008ktL-2IWQ for linux-arm-kernel@lists.infradead.org; Fri, 02 Aug 2024 12:01:52 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C50BC1007; Fri, 2 Aug 2024 05:02:15 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 642163F64C; Fri, 2 Aug 2024 05:01:46 -0700 (PDT) Message-ID: Date: Fri, 2 Aug 2024 13:01:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure To: niliqiang , jean-philippe@linaro.org Cc: Jonathan.Cameron@huawei.com, baolu.lu@linux.intel.com, devicetree@vger.kernel.org, eric.auger@redhat.com, guohanjun@huawei.com, iommu@lists.linux-foundation.org, jacob.jun.pan@linux.intel.com, joro@8bytes.org, kevin.tian@intel.com, lenb@kernel.org, linux-accelerators@lists.ozlabs.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com, rjw@rjwysocki.net, robh+dt@kernel.org, shameerali.kolothum.thodi@huawei.com, sudeep.holla@arm.com, vivek.gautam@arm.com, wangzhou1@hisilicon.com, will@kernel.org, zhangfei.gao@linaro.org, zhukeqian1@huawei.com, ni.liqiang@zte.com.cn, li.zhichao@zte.com.cn References: <20210401154718.307519-8-jean-philippe@linaro.org> <20240801152922.5605-1-ni_liqiang@126.com> From: Robin Murphy Content-Language: en-GB In-Reply-To: <20240801152922.5605-1-ni_liqiang@126.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240802_050151_674223_999B7253 X-CRM114-Status: GOOD ( 14.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.