From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 4BB71284883 for ; Fri, 22 May 2026 06:01:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779429668; cv=none; b=p87NlmvKx9s4a6Pb/A2MvaU3eJx+FVn4gBgtX13FJ4ZIN5Dr/0opPjNTgolo3B/bsdlzrhWZPnRMl2B9T3idIIaJUCONGf5DUTWHTlH3Ycz3t80FVXxmIjCj4yu0DHDLXu2EX5WIywSfNJa6Y4MLd/CKcnVnD6ehgsFJOFvm+Tw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779429668; c=relaxed/simple; bh=C+fQAK78vh42D0+3zrcP8ofL6wgnDgmB5Aiv9yoILVs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cujLWfCtLKKdO1tovJcqRgkVWEhg2zPAcUsx+4amf33L5dxKtjXM0cKrWp9iTlxPUEwazP+Zg3+tAKegVTbpPgUNxQ1MZSy0qyGLW1cf0Db0v1cX/eZjlvkCv7FXafH2yvBWax9QslYefChzYLvSk4JeMk1qpGX/tAKZFk9Z/O4= 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=IxFq+R8l; arc=none smtp.client-ip=198.175.65.15 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="IxFq+R8l" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779429667; x=1810965667; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=C+fQAK78vh42D0+3zrcP8ofL6wgnDgmB5Aiv9yoILVs=; b=IxFq+R8lqUro0usF8vFvhjZwdkVtGDTDe/O1Zr817w+A9nniqvv/90DJ 3P3HOAGP42Oh8+0p/Pvi6KWbTlCfiHzu7Nq0e7K8gvWZAAZOu7CyLqqj0 zWc8RjmMjFIHY2pPcJ0F9Q3SkL0ObtAx9HEyB427C/yz79qj0Cvk1B6hT uZUlU0WoXr2RvyJyJIiZubA7B+wRG9VDz30CuPojHvqhhmt4A4h2FJ2Ty N2Gb9efUDP/Uchiq3TAL6E5rA8ciiHLUG54j+mqt1+7FDsZyjkl6/xoTb 1EbXoGmQTdtYBuLTEE3Rkla3tabxAj0yLSGqH+3jXKsvqQ9fOdUcp+bla g==; X-CSE-ConnectionGUID: S4aWP8jYSIScRtgsTXKWgA== X-CSE-MsgGUID: HwKy5cj0RqKIhaGBY9WEKQ== X-IronPort-AV: E=McAfee;i="6800,10657,11793"; a="83973216" X-IronPort-AV: E=Sophos;i="6.24,161,1774335600"; d="scan'208";a="83973216" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2026 23:01:06 -0700 X-CSE-ConnectionGUID: RrqZfG94TR+DQ2AfE9jg+A== X-CSE-MsgGUID: rl4EJfF/TYqjQq4egtnVDw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,161,1774335600"; d="scan'208";a="237775076" Received: from allen-sbox.sh.intel.com (HELO [10.239.159.30]) ([10.239.159.30]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2026 23:01:02 -0700 Message-ID: Date: Fri, 22 May 2026 14:00:28 +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 v6 2/7] 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: <20260521221155.1375144-1-jacob.pan@linux.microsoft.com> <20260521221155.1375144-3-jacob.pan@linux.microsoft.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <20260521221155.1375144-3-jacob.pan@linux.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/22/26 06:11, 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() > 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); nit: I am still wondering why kzalloc_obj() was replaced with kzalloc() here. Is it a rebase issue or something that was left out of the commit message? Otherwise, I am fine with it, Reviewed-by: Lu Baolu > + 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.