Message ID | 20230217094736.159005-4-baolu.lu@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp800450wrn; Fri, 17 Feb 2023 02:03:35 -0800 (PST) X-Google-Smtp-Source: AK7set+d7wo1/ytAzeDlTXelCCG7DlZ8vzBPRz27ZBApqy/GBDDfGFlhI6xLxOtb7ZtI7gs1BcaF X-Received: by 2002:a05:6a20:9383:b0:be:ffb5:e41d with SMTP id x3-20020a056a20938300b000beffb5e41dmr281484pzh.25.1676628215096; Fri, 17 Feb 2023 02:03:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676628215; cv=none; d=google.com; s=arc-20160816; b=D9xtthbsHsqVSTFLcshcmwrN1u9gGonY8BBy6pFDInUpeCVpZzrpSnasGT9fszMGDr R2JPQCBXLFmsEPiBR8IAoMmBWYi5xNZ/SHzt7HmlXak7dCo3vpHNqvZiMLDBPv51yHYJ 8rgCiHlynwI3hQT1VddUoutWvYvsb+pTZoUq5RhExhJ1I0SGgGWSOk4uHANF4QpOFT29 GXGzLiVrc7bJpKT9MJY+ut2k34fUoG2Na05Zd/Sq1ajiDWbIfwPAYfgp5Kos8Pgy/han t6VpkMBBguTJ24DH18m98Dh3cFr5tbfRFiRnQMtHCLUVYYEiRTRqx2tTDY2yow2QiNRZ 99jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Ff5JjfgbLvGtAdsNxEwOJ6xro97bPAzhgPOL5xkLsE8=; b=r5qxewI6/nN5D4FduRc9xzV7SloghU5trPJMQVZUYpRqRHR356d0G8sWWLnG9v+Ug4 fUmhPwe/Ppb/LWcpQ7Wrx9I2xvMh4wX5ddtn13Qs1wY88bdD91swgEti+pvt99TmmUDC skRu0OBofKiDgDaEpk6rHH2YC18YYucZnt3FEppZQ0s2uGmAmSdFdvpjWVS5Xq6j25/H farwgtt6rF28mi/TGTSr+KV80wnr7HlI5gEPo2ojtcv5zGH2lAUDFUYMaGxwnDzKJfeo PphmYmloKLPBQ4Enwcb6fK57EUqb0sT/Mpec8PdgQG3TOGNxFxvV06c2M1kCkBtjHBVx Trjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=L8PL5LIf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x140-20020a633192000000b004fbcd0785casi5072726pgx.207.2023.02.17.02.03.21; Fri, 17 Feb 2023 02:03:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=L8PL5LIf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230210AbjBQJ42 (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Fri, 17 Feb 2023 04:56:28 -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 <rfc822;linux-kernel@vger.kernel.org>); 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 <linux-kernel@vger.kernel.org>; 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 <baolu.lu@linux.intel.com> To: iommu@lists.linux.dev Cc: Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>, Christoph Hellwig <hch@infradead.org>, Kevin Tian <kevin.tian@intel.com>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com> 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: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758072107229558249?= X-GMAIL-MSGID: =?utf-8?q?1758072107229558249?= |
Series |
iommu: Extend changing default domain to normal group
|
|
Commit Message
Baolu Lu
Feb. 17, 2023, 9:47 a.m. UTC
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 <baolu.lu@linux.intel.com>
---
drivers/iommu/iommu.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
Comments
On Fri, Feb 17, 2023 at 05:47:33PM +0800, Lu Baolu wrote: > 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 <baolu.lu@linux.intel.com> > --- > 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); Seems like a hunk is missing from this patch? Jason
On 2/17/23 11:40 PM, Jason Gunthorpe wrote: > On Fri, Feb 17, 2023 at 05:47:33PM +0800, Lu Baolu wrote: >> 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<baolu.lu@linux.intel.com> >> --- >> 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); > Seems like a hunk is missing from this patch? Did you mean below block of change? If so, I will add it in the next version. + + /* + * If the group has become empty then ownership must have been released, + * and the current domain must be set back to NULL or the default + * domain. + */ + if (list_empty(&group->devices)) + WARN_ON(group->owner_cnt || + group->domain != group->default_domain); + + /* + * release_device() must stop using any attached domain on the device. + * If there are still other devices in the group they are not effected + * by this callback. + * + * The IOMMU driver must set the device to either an identity or + * blocking translation and stop using any domain pointer, as it is + * going to be freed. + */ if (ops->release_device) ops->release_device(dev); + mutex_unlock(&group->mutex); By the way, can I add you signed-off-by when I use the code you posted in the discussion thread? Best regards, baolu
On Sat, Feb 18, 2023 at 03:29:12PM +0800, Baolu Lu wrote: > On 2/17/23 11:40 PM, Jason Gunthorpe wrote: > > On Fri, Feb 17, 2023 at 05:47:33PM +0800, Lu Baolu wrote: > > > 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<baolu.lu@linux.intel.com> > > > --- > > > 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); > > Seems like a hunk is missing from this patch? > > Did you mean below block of change? If so, I will add it in the next > version. I mean this changed the protoype but I didn't see a change in the actual funtion? > By the way, can I add you signed-off-by when I use the code you posted > in the discussion thread? Yes Jason
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); #define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \ struct iommu_group_attribute iommu_group_attr_##_name = \ @@ -466,18 +470,25 @@ int iommu_probe_device(struct device *dev) void iommu_release_device(struct device *dev) { + struct iommu_group *group = dev->iommu_group; + struct group_device *device; const struct iommu_ops *ops; - if (!dev->iommu) + if (!dev->iommu || !group) return; iommu_device_unlink(dev->iommu->iommu_dev, dev); + mutex_lock(&group->mutex); ops = dev_iommu_ops(dev); if (ops->release_device) ops->release_device(dev); + device = __iommu_group_remove_device(group, dev); + mutex_unlock(&group->mutex); + + if (device) + __iommu_group_release_device(group, device); - iommu_group_remove_device(dev); module_put(ops->owner); dev_iommu_free(dev); }