Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Thu, 12 Oct 2023 10:43:10 -0300
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Tina Zhang <tina.zhang@intel.com>
Cc:     Kevin Tian <kevin.tian@intel.com>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Michael Shavit <mshavit@google.com>,
        Vasant Hegde <vasant.hegde@amd.com>,
        "Nicolin Chen ^C-cc=iommu @ lists . linux . dev" 
        <nicolinc@nvidia.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 4/5] iommu: Support mm PASID 1:n with sva domains
Message-ID: <20231012134310.GI55194@ziepe.ca>
References: <20231012030112.82270-1-tina.zhang@intel.com>
 <20231012030112.82270-5-tina.zhang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231012030112.82270-5-tina.zhang@intel.com>
Precedence: bulk

On Thu, Oct 12, 2023 at 11:01:11AM +0800, Tina Zhang wrote:

> @@ -1188,15 +1193,26 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
>  #ifdef CONFIG_IOMMU_SVA
>  static inline void mm_pasid_init(struct mm_struct *mm)
>  {
> -	mm->pasid = IOMMU_PASID_INVALID;
> +	/*
> +	 * During dup_mm(), a new mm will be memcpy'd from an old one and that makes
> +	 * the new mm and the old one point to a same iommu_mm instance. When either
> +	 * one of the two mms gets released, the iommu_mm instance is freed, leaving
> +	 * the other mm running into a use-after-free/double-free problem. To avoid
> +	 * the problem, zeroing the iommu_mm pointer of a new mm is needed here.
> +	 */
> +	mm->iommu_mm = NULL;
>  }

newlines after all the }, between functions doesn't checkpatch
complain?

IMHO this hunk should be moved to the prior patch.

But it all looks good to me now

Thanks,
Jason