From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F96A7462 for ; Fri, 14 Jul 2023 06:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689314420; x=1720850420; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=UXRTaxPUMTttyEK6k/XZG4rdkxjidqSuECmGEg2DEto=; b=Vu5srnwNBqeM8Y2+4V+nP3CZ2EhJclJMMrg3U9Lgw/Q6UxAAfqPDd5/T xISFY44VsYh3yGXgbqZ/ph7LhbZy/e5EWa2goNUul5+71pSvy59O2IdVt vkCvcv14yZkGvspTih8NugPQI45KdpmAjUN7vV8emsuxFPUb3adzBqHpE pBkZvzPj9QcoDe8umz17gWBxOvwZKGV6VikO85eMVhBG394EZi7dnca4M OIyKwxehOADEyxRr1o84xNRuXruIY6F4JTNqOUBHc2JnzHeyY3zDLCd0t Yw4BLisIJzk+Dw4xafViyVFOEvENKfcOsDcVFZIcuSxgc2ZTSSfQZGjI9 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="368949767" X-IronPort-AV: E=Sophos;i="6.01,204,1684825200"; d="scan'208";a="368949767" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 23:00:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="835910869" X-IronPort-AV: E=Sophos;i="6.01,204,1684825200"; d="scan'208";a="835910869" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.252.187.116]) ([10.252.187.116]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 23:00:14 -0700 Message-ID: <2a103a6d-af9f-456d-eda4-f1e15f8367b6@linux.intel.com> Date: Fri, 14 Jul 2023 14:00:07 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: baolu.lu@linux.intel.com, Jason Gunthorpe , Will Deacon , "Liu, Yi L" , "Yu, Fenghua" , "Luck, Tony" Subject: Re: [PATCH v10 6/7] iommu/vt-d: Add set_dev_pasid callback for dma domain Content-Language: en-US To: "Tian, Kevin" , Jacob Pan , LKML , "iommu@lists.linux.dev" , Joerg Roedel , Jean-Philippe Brucker , Robin Murphy References: <20230712163355.3177511-1-jacob.jun.pan@linux.intel.com> <20230712163355.3177511-7-jacob.jun.pan@linux.intel.com> <87e78302-9f69-8db1-8a0a-b40e1f29d9c6@linux.intel.com> From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023/7/14 11:50, Tian, Kevin wrote: >> From: Baolu Lu >> Sent: Friday, July 14, 2023 11:34 AM >> >> On 2023/7/13 15:56, Tian, Kevin wrote: >>>> From: Jacob Pan >>>> Sent: Thursday, July 13, 2023 12:34 AM >>>> >>>> >>>> - /* >>>> - * Should never reach here until we add support for attaching >>>> - * non-SVA domain to a pasid. >>>> - */ >>>> - WARN_ON(1); >>>> + dmar_domain = to_dmar_domain(domain); >>>> + spin_lock_irqsave(&dmar_domain->lock, flags); >>>> + list_for_each_entry(curr, &dmar_domain->dev_pasids, link_domain) >>>> { >>>> + if (curr->dev == dev && curr->pasid == pasid) { >>>> + list_del(&curr->link_domain); >>>> + dev_pasid = curr; >>>> + break; >>>> + } >>>> + } >>>> + spin_unlock_irqrestore(&dmar_domain->lock, flags); >>>> >>> >>> what about no matching dev_pasid is find? >> >> kfree() can handle this gracefully. > > but what about domain_detach_iommu()? Is it correct to adjust > the refcnting when there is no matching dev_pasid? You are right. Logically, if we get a valid domain for a pasid, we should have a dev_pasid allocated for it. Perhaps, adding a check in the code will make the code more readable? Best regards, baolu