From nobody Thu Sep 11 18:24:15 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81215C636D4 for ; Fri, 17 Feb 2023 09:56:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229787AbjBQJ43 (ORCPT ); Fri, 17 Feb 2023 04:56:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230203AbjBQJ4S (ORCPT ); Fri, 17 Feb 2023 04:56:18 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8D7562FF2 for ; Fri, 17 Feb 2023 01:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676627776; x=1708163776; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=svzPQoaIiOVo1++kdQiL9mjZd3QRrwDo4zYQS1l6NZs=; b=L8PL5LIfdTA32AiWtGMez2yqtM0W+MfFCuUw7O2xE/hoU9R33JtJ9las DhaxIhK5k/uPijXGeB6VzegP7oTR0M+NJ5mLueRXiGbosSrLr+zmlGBul Zd1+/Nva01STpQJHRk9hyKL8CdTM1Qor+wNUoqEWOwP4E2DMmxjPCgieT WnACZ8JcTBvLUY87t2Hj+E5on66Q6EKafpPan2yyeg+Bwr7RDQFqtF/M+ RWoEo9yfqUxJen5x8ihAzNHWpHbEv/JWrMg6kPz8Ijs/wMqBBido9NSTj JlHLpTaKNfWMyOnQsI3JMXvuJjCUVlSg6Ni699gW026PjhaoXXm8mMslt g==; X-IronPort-AV: E=McAfee;i="6500,9779,10623"; a="331955232" X-IronPort-AV: E=Sophos;i="5.97,304,1669104000"; d="scan'208";a="331955232" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2023 01:56:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10623"; a="999391225" X-IronPort-AV: E=Sophos;i="5.97,304,1669104000"; d="scan'208";a="999391225" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga005.fm.intel.com with ESMTP; 17 Feb 2023 01:56:13 -0800 From: Lu Baolu To: iommu@lists.linux.dev Cc: Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , Kevin Tian , Will Deacon , Robin Murphy , linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH v2 3/6] iommu: Same critical region for device release and removal Date: Fri, 17 Feb 2023 17:47:33 +0800 Message-Id: <20230217094736.159005-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230217094736.159005-1-baolu.lu@linux.intel.com> References: <20230217094736.159005-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In a non-driver context, it is crucial to ensure the consistency of a device's iommu ops. Otherwise, it may result in a situation where a device is released but it's iommu ops are still used. Put the ops->release_device and __iommu_group_remove_device() in a some group->mutext critical region, so that, as long as group->mutex is held and the device is in its group's device list, its iommu ops are always consistent. Signed-off-by: Lu Baolu --- drivers/iommu/iommu.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 6247883991e2..093692308b80 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -101,6 +101,10 @@ static int iommu_create_device_direct_mappings(struct = iommu_group *group, static struct iommu_group *iommu_group_get_for_dev(struct device *dev); static ssize_t iommu_group_store_type(struct iommu_group *group, const char *buf, size_t count); +static struct group_device * +__iommu_group_remove_device(struct iommu_group *group, struct device *dev); +static void __iommu_group_release_device(struct iommu_group *group, + struct group_device *grp_dev); =20 #define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \ struct iommu_group_attribute iommu_group_attr_##_name =3D \ @@ -466,18 +470,25 @@ int iommu_probe_device(struct device *dev) =20 void iommu_release_device(struct device *dev) { + struct iommu_group *group =3D dev->iommu_group; + struct group_device *device; const struct iommu_ops *ops; =20 - if (!dev->iommu) + if (!dev->iommu || !group) return; =20 iommu_device_unlink(dev->iommu->iommu_dev, dev); =20 + mutex_lock(&group->mutex); ops =3D dev_iommu_ops(dev); if (ops->release_device) ops->release_device(dev); + device =3D __iommu_group_remove_device(group, dev); + mutex_unlock(&group->mutex); + + if (device) + __iommu_group_release_device(group, device); =20 - iommu_group_remove_device(dev); module_put(ops->owner); dev_iommu_free(dev); } --=20 2.34.1