From: Baolu Lu <baolu.lu@linux.intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Jason Gunthorpe <jgg@nvidia.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Pranjal Shrivastava <praan@google.com>,
Mostafa Saleh <smostafa@google.com>,
Kevin Tian <kevin.tian@intel.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-pci@vger.kernel.org, vsethi@nvidia.com,
Shuai Xue <xueshuai@linux.alibaba.com>
Subject: Re: [PATCH v3 02/11] iommu: Pass in reset result to pci_dev_reset_iommu_done()
Date: Fri, 24 Apr 2026 10:56:31 +0800 [thread overview]
Message-ID: <fa3d734c-4447-4b7b-9a8d-bb95ffd0e851@linux.intel.com> (raw)
In-Reply-To: <aerZa3aQBMCwzzT8@Asurada-Nvidia>
On 4/24/26 10:46, Nicolin Chen wrote:
> On Fri, Apr 24, 2026 at 10:38:09AM +0800, Baolu Lu wrote:
>> On 4/17/26 07:28, Nicolin Chen wrote:
>>> @@ -4083,6 +4093,18 @@ void pci_dev_reset_iommu_done(struct pci_dev *pdev)
>>> if (WARN_ON(!group->blocking_domain))
>>> return;
>>> + /*
>>> + * A reset failure implies that the device might be unreliable. E.g. its
>>> + * device cache might retain stale entries, which potentially results in
>>> + * memory corruption. Thus, do not unblock the device until a successful
>>> + * reset.
>>> + */
>>> + if (!reset_succeeds) {
>>> + pci_err(pdev,
>>> + "Reset failed. Keep it blocked to protect memory\n");
>>> + return;
>>> + }
>>
>> Nit: pci_dev_reset_iommu_done() does nothing if reset_succeeds is false.
>> Would it be better to handle this in the caller instead? Something like:
>>
>> if (reset_succeeds)
>> pci_dev_reset_iommu_done(dev);
>>
>> ?
>
> It would also need a print and some duplicated comments. Actually,
> that would be my v2, which Kevin suggested this against:
> https://lore.kernel.org/all/BN9PR11MB5276706AE4E0BBE86F0F6E158C4EA@BN9PR11MB5276.namprd11.prod.outlook.com/
Oh, I forgot that comment.
> Though I don't have a strong personal reference here, I do see this
> version slightly cleaner than doing in the callers.
Okay, you own the decision.
> Thanks
> Nicolin
Thanks,
baolu
next prev parent reply other threads:[~2026-04-24 2:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 23:28 [PATCH v3 00/11] iommu/arm-smmu-v3: Quarantine device upon ATC invalidation timeout Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 01/11] PCI: Propagate FLR return values to callers Nicolin Chen
2026-04-22 6:13 ` Baolu Lu
2026-04-23 4:29 ` Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 02/11] iommu: Pass in reset result to pci_dev_reset_iommu_done() Nicolin Chen
2026-04-24 2:38 ` Baolu Lu
2026-04-24 2:46 ` Nicolin Chen
2026-04-24 2:56 ` Baolu Lu [this message]
2026-04-16 23:28 ` [PATCH v3 03/11] iommu: Add reset_device_done callback for hardware fault recovery Nicolin Chen
2026-04-24 2:40 ` Baolu Lu
2026-04-16 23:28 ` [PATCH v3 04/11] iommu: Add __iommu_group_block_device helper Nicolin Chen
2026-04-24 2:40 ` Baolu Lu
2026-04-16 23:28 ` [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list Nicolin Chen
2026-04-24 2:53 ` Baolu Lu
2026-04-24 3:08 ` Nicolin Chen
2026-04-24 13:11 ` Jason Gunthorpe
2026-04-24 19:12 ` Nicolin Chen
2026-04-24 22:58 ` Jason Gunthorpe
2026-04-25 0:51 ` Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 06/11] iommu: Defer __iommu_group_free_device() to be outside group->mutex Nicolin Chen
2026-04-23 7:55 ` Baolu Lu
2026-04-23 15:47 ` Nicolin Chen
2026-04-24 2:29 ` Baolu Lu
2026-04-16 23:28 ` [PATCH v3 07/11] iommu: Add iommu_report_device_broken() to quarantine a broken device Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 08/11] iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 09/11] iommu/arm-smmu-v3: Replace smmu with master in arm_smmu_inv Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 10/11] iommu/arm-smmu-v3: Introduce master->ats_broken flag Nicolin Chen
2026-04-16 23:28 ` [PATCH v3 11/11] iommu/arm-smmu-v3: Block ATS upon an ATC invalidation timeout Nicolin Chen
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=fa3d734c-4447-4b7b-9a8d-bb95ffd0e851@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=vsethi@nvidia.com \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.