All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH 5/6] iommu/amd: Fail probe on ATS configuration failure
Date: Mon, 1 Jun 2026 15:05:37 +0000	[thread overview]
Message-ID: <ah2fwcxzdhx8N0FR@google.com> (raw)
In-Reply-To: <20260601150126.3E04E1F00893@smtp.kernel.org>

On Mon, Jun 01, 2026 at 03:01:25PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The newly added WARN_ON(ret) in pdev_enable_cap_ats() can be spuriously triggered for SR-IOV Virtual Functions (VFs) if the Physical Function (PF) was not properly configured for ATS.
> --
> 
> commit 40ae1c6d486f021eadc253f746299ffa4ca11dff
> Author: Pranjal Shrivastava <praan@google.com>
> 
> iommu/amd: Fail probe on ATS configuration failure
> 
> This commit updates the AMD IOMMU driver to call pci_prepare_ats() during
> device probe, failing the probe if it returns an error. It also adds a
> WARN_ON() in pdev_enable_cap_ats() to catch failures from pci_enable_ats().
> 
> > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> > index 4ef6024c5a4ea..783f53cb85996 100644
> > --- a/drivers/iommu/amd/iommu.c
> > +++ b/drivers/iommu/amd/iommu.c
> > @@ -566,10 +566,17 @@ static inline int pdev_enable_cap_ats(struct pci_dev *pdev)
> >  	if (amd_iommu_iotlb_sup &&
> >  	    (dev_data->flags & AMD_IOMMU_DEVICE_FLAG_ATS_SUP)) {
> >  		ret = pci_enable_ats(pdev, PAGE_SHIFT);
> > -		if (!ret) {
> > -			dev_data->ats_enabled = 1;
> > -			dev_data->ats_qdep    = pci_ats_queue_depth(pdev);
> > -		}
> > +
> > +		/*
> > +		 * pci_enable_ats() should not fail here because earlier
> > +		 * checks have already verified support & config.
> > +		 */
> > +		if (WARN_ON(ret))
> > +			return ret;
> 
> [Severity: High]
> Can this WARN_ON() trigger spuriously for SR-IOV Virtual Functions (VFs) if
> the Physical Function (PF) was not properly configured for ATS?
> 
> Looking at pci_prepare_ats(), it has a fast-path that returns 0 immediately
> for VFs without checking or configuring the PF's Smallest Translation Unit
> (STU):
> 
> int pci_prepare_ats(struct pci_dev *dev, int ps)
> {
>     ...
>     if (dev->is_virtfn)
>         return 0;
>     ...
> }
> 
> Later, when pdev_enable_cap_ats() calls pci_enable_ats() for the VF, the
> actual validation happens there:
> 
> int pci_enable_ats(struct pci_dev *dev, int ps)
> {
>     ...
>     if (pdev->ats_stu != ps)
>         return -EINVAL;
>     ...
> }
> 
> If the PF failed its IOMMU probe or was explicitly bypassed by the driver,
> its ats_stu would remain 0.
> 
> When VFs are subsequently probed, pci_prepare_ats() would blindly succeed,
> but pci_enable_ats() would fail with -EINVAL, triggering this new WARN_ON().
> 
> Could this lead to unnecessary bug reports or kernel crashes on systems
> configured with panic_on_warn?

No.. this error won't be hit because the path highlighted above is being
changed in the ATS series:

https://lore.kernel.org/all/20260601143644.2358771-3-praan@google.com/

Thanks,
Praan

  reply	other threads:[~2026-06-01 15:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 13:41 [PATCH 0/6] iommu/amd: Refactors for ATS updates Pranjal Shrivastava
2026-06-01 13:41 ` [PATCH 1/6] iommu/amd: Clear aliases before setting the rlookup_table to NULL Pranjal Shrivastava
2026-06-01 13:57   ` sashiko-bot
2026-06-01 13:42 ` [PATCH 2/6] iommu/amd: Clear DTE with update_dte256 in iommu_ignore_device() Pranjal Shrivastava
2026-06-01 14:09   ` sashiko-bot
2026-06-01 14:19   ` Jason Gunthorpe
2026-06-02  4:01     ` Pranjal Shrivastava
2026-06-02  8:55   ` Vasant Hegde
2026-06-01 13:42 ` [PATCH 3/6] iommu/amd: Split probe error paths to preserve IRQ remapping Pranjal Shrivastava
2026-06-01 14:30   ` sashiko-bot
2026-06-01 13:42 ` [PATCH 4/6] iommu/amd: Fix Use-After-Free in non-fatal probe error path Pranjal Shrivastava
2026-06-01 14:44   ` sashiko-bot
2026-06-01 13:42 ` [PATCH 5/6] iommu/amd: Fail probe on ATS configuration failure Pranjal Shrivastava
2026-06-01 15:01   ` sashiko-bot
2026-06-01 15:05     ` Pranjal Shrivastava [this message]
2026-06-01 13:42 ` [PATCH 6/6] PCI/ATS: Mandate checking pci_ats_supported() before pci_prepare_ats() Pranjal Shrivastava
2026-06-01 19:06   ` sashiko-bot
2026-06-02  8:49 ` [PATCH 0/6] iommu/amd: Refactors for ATS updates Vasant Hegde
2026-06-02 12:08   ` Jason Gunthorpe
2026-06-04  8:23     ` Vasant Hegde

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=ah2fwcxzdhx8N0FR@google.com \
    --to=praan@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.