From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Badger, Eric" <ebadger@purestorage.com>
Cc: baolu.lu@linux.intel.com,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] iommu/vt-d: Fix NULL domain on device release
Date: Wed, 28 Feb 2024 09:22:42 +0800 [thread overview]
Message-ID: <64a1f1ff-793d-4bf7-91fc-00984336594c@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB52763D19A01C804FB514419F8C592@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2/27/24 3:40 PM, Tian, Kevin wrote:
>> From: Lu Baolu<baolu.lu@linux.intel.com>
>> Sent: Friday, February 23, 2024 1:13 PM
>>
>> -static void dmar_remove_one_dev_info(struct device *dev)
>> -{
>> - struct device_domain_info *info = dev_iommu_priv_get(dev);
>> - struct dmar_domain *domain = info->domain;
>> - struct intel_iommu *iommu = info->iommu;
>> - unsigned long flags;
>> -
>> - if (!dev_is_real_dma_subdevice(info->dev)) {
>> - if (dev_is_pci(info->dev) && sm_supported(iommu))
>> - intel_pasid_tear_down_entry(iommu, info->dev,
>> - IOMMU_NO_PASID, false);
>> -
>> - iommu_disable_pci_caps(info);
>> - domain_context_clear(info);
>> - }
>> -
>> - spin_lock_irqsave(&domain->lock, flags);
>> - list_del(&info->link);
>> - spin_unlock_irqrestore(&domain->lock, flags);
>> -
>> - domain_detach_iommu(domain, iommu);
>> - info->domain = NULL;
>> -}
>> -
> what's required here is slightly different from device_block_translation()
> which leaves context entry uncleared in scalable mode (implying the
> pasid table must be valid). but in the release path the pasid table will
> be freed right after then leading to a use-after-free case.
>
> let's add an explicit domain_context_clear() in intel_iommu_release_device().
Nice catch!
How about moving the scalable mode context entry management to probe and
release path? Currently, it's part of domain switch, that's really
irrelevant.
Best regards,
baolu
next prev parent reply other threads:[~2024-02-28 1:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 5:13 [PATCH 0/2] iommu: Fix domain check " Lu Baolu
2024-02-23 5:13 ` [PATCH 1/2] iommu: Add static iommu_ops->release_domain Lu Baolu
2024-02-27 7:32 ` Tian, Kevin
2024-02-28 1:13 ` Baolu Lu
2024-02-28 3:08 ` Tian, Kevin
2024-02-28 3:30 ` Baolu Lu
2024-02-23 5:13 ` [PATCH 2/2] iommu/vt-d: Fix NULL domain on device release Lu Baolu
2024-02-27 7:40 ` Tian, Kevin
2024-02-28 1:22 ` Baolu Lu [this message]
2024-02-28 3:08 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64a1f1ff-793d-4bf7-91fc-00984336594c@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ebadger@purestorage.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome