From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 2DC803D6695 for ; Wed, 13 May 2026 07:18:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778656722; cv=none; b=VH0ZN3J0vpOFwjMMbU9rTFY7d3GJ4+aZV7GHVURad899Y3du+6krJP4G2enXubELe+wjl2FKN4WU/QR9o1dTVezsylHCzzQonTm9scwl795cuF9WecLZ7On97jOE4XIJZykCC0XxsFHm8tnK2I/9+pFciMouoH5m+Wy9YajVd1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778656722; c=relaxed/simple; bh=Q74nb8qKOTOSF9NKkRDYzNFp0wpByFW+gJjBCBJqJpI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ApbfYIzVcnpPhOvNE8fIs0aFpMppo2NnJ5w1joWc8ZILarrfGvR+LYpHmoFkl/Np52fHrE2gVXfj2801KnyktI+Dusd1lNewhdzHOBD3fIrCiXralCYWnRqA8HTzOfKQ9lbjJK2YwwiThJ9e5QS2L8iv/WKAWHzv5UNqGgVljv8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=CJFkQioD; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="CJFkQioD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778656719; x=1810192719; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Q74nb8qKOTOSF9NKkRDYzNFp0wpByFW+gJjBCBJqJpI=; b=CJFkQioD2N5a5REHagKJRWG+0bnx5E/1DNF/9Mdz4APBnVCRYCu1xiUG eMnNTzEnfRrHxtLyxxYrfc2fZWpKFBUC8Hk9SjelHW+b1e1cP/VQZli8P /djkTPIBUzeLPTR2o8ZS2Iwft5TdvfY7BVYpzyW+VswDBphxYCk5j/1jn joi5PMd4YUxPkE2z5SFGW1gjjLygcjfTizvMSdsTz/GF8s+Uu5lL7ku6b YYuI6rTe7VE02DnmIpK8cMz5xzytsqxtk83fMWhNEtqThe3bDuDJe1LVG FMvr9lHAScuuWJxVdFL4gVCn/b7ITAHeZFQS6l7wB2wJqIjggCemYBpcR w==; X-CSE-ConnectionGUID: inhEEHqvTl6zkWXmNTBucQ== X-CSE-MsgGUID: X5bXICp4QW2i25VdQAZQ8Q== X-IronPort-AV: E=McAfee;i="6800,10657,11784"; a="105036085" X-IronPort-AV: E=Sophos;i="6.23,232,1770624000"; d="scan'208";a="105036085" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2026 00:18:39 -0700 X-CSE-ConnectionGUID: DaHO4JUAQEiRJGy9Q00Q4Q== X-CSE-MsgGUID: lk23AwN+RO+DMvJyABi1HQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,232,1770624000"; d="scan'208";a="237916339" Received: from allen-sbox.sh.intel.com (HELO [10.239.159.30]) ([10.239.159.30]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2026 00:18:35 -0700 Message-ID: Date: Wed, 13 May 2026 15:18:17 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 3/9] iommufd: Move igroup allocation to a function To: Jacob Pan , linux-kernel@vger.kernel.org, "iommu@lists.linux.dev" , Jason Gunthorpe , Alex Williamson , Joerg Roedel , Mostafa Saleh , David Matlack , Robin Murphy , Nicolin Chen , "Tian, Kevin" , Yi Liu Cc: Saurabh Sengar , skhawaja@google.com, pasha.tatashin@soleen.com, Will Deacon References: <20260511184116.3687392-1-jacob.pan@linux.microsoft.com> <20260511184116.3687392-4-jacob.pan@linux.microsoft.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <20260511184116.3687392-4-jacob.pan@linux.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/12/26 02:41, Jacob Pan wrote: > From: Jason Gunthorpe > > So it can be reused in the next patch which allows binding to noiommu > device. > > Reviewed-by: Samiullah Khawaja > Reviewed-by: Yi Liu > Reviewed-by: Kevin Tian > Signed-off-by: Jason Gunthorpe > Signed-off-by: Jacob Pan > --- > v5: > - Add NULL group to the error handling path of > iommufd_group_setup_msi() This logic is not visible in the patch's diff. Perhaps anything I overlooked? > v3: > - New patch > --- > drivers/iommu/iommufd/device.c | 43 +++++++++++++++++++++------------- > 1 file changed, 27 insertions(+), 16 deletions(-) > > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c > index 170a7005f0bc..d03076fcf3c2 100644 > --- a/drivers/iommu/iommufd/device.c > +++ b/drivers/iommu/iommufd/device.c > @@ -56,6 +56,30 @@ static bool iommufd_group_try_get(struct iommufd_group *igroup, > return kref_get_unless_zero(&igroup->ref); > } > > +static struct iommufd_group *iommufd_alloc_group(struct iommufd_ctx *ictx, > + struct iommu_group *group) > +{ > + struct iommufd_group *new_igroup; > + > + new_igroup = kzalloc(sizeof(*new_igroup), GFP_KERNEL); kzalloc_obj() is replaced with kzalloc(). Can you please explain the reason? > + if (!new_igroup) > + return ERR_PTR(-ENOMEM); > + > + kref_init(&new_igroup->ref); > + mutex_init(&new_igroup->lock); > + xa_init(&new_igroup->pasid_attach); > + new_igroup->sw_msi_start = PHYS_ADDR_MAX; > + /* group reference moves into new_igroup */ > + new_igroup->group = group; > + > + /* > + * The ictx is not additionally refcounted here because all objects using > + * an igroup must put it before their destroy completes. > + */ > + new_igroup->ictx = ictx; > + return new_igroup; > +} > + > /* > * iommufd needs to store some more data for each iommu_group, we keep a > * parallel xarray indexed by iommu_group id to hold this instead of putting it > @@ -87,25 +111,12 @@ static struct iommufd_group *iommufd_get_group(struct iommufd_ctx *ictx, > } > xa_unlock(&ictx->groups); > > - new_igroup = kzalloc_obj(*new_igroup); > - if (!new_igroup) { > + new_igroup = iommufd_alloc_group(ictx, group); > + if (IS_ERR(new_igroup)) { > iommu_group_put(group); > - return ERR_PTR(-ENOMEM); > + return new_igroup; > } > > - kref_init(&new_igroup->ref); > - mutex_init(&new_igroup->lock); > - xa_init(&new_igroup->pasid_attach); > - new_igroup->sw_msi_start = PHYS_ADDR_MAX; > - /* group reference moves into new_igroup */ > - new_igroup->group = group; > - > - /* > - * The ictx is not additionally refcounted here becase all objects using > - * an igroup must put it before their destroy completes. > - */ > - new_igroup->ictx = ictx; > - > /* > * We dropped the lock so igroup is invalid. NULL is a safe and likely > * value to assume for the xa_cmpxchg algorithm. Otherwise this patch looks good to me, Reviewed-by: Lu Baolu