From: Pranjal Shrivastava <praan@google.com>
To: iommu@lists.linux.dev
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Mostafa Saleh <smostafa@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
Samiullah Khawaja <skhawaja@google.com>,
Daniel Mentz <danielmentz@google.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Matlack <dmatlack@google.com>
Subject: Re: [PATCH rc] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking
Date: Mon, 4 May 2026 16:40:18 +0000 [thread overview]
Message-ID: <afjL8sUdlFCdVfno@google.com> (raw)
In-Reply-To: <20260504125343.2088858-1-praan@google.com>
On Mon, May 04, 2026 at 12:53:42PM +0000, Pranjal Shrivastava wrote:
> arm_smmu_enable_ats() ignores the return value of pci_enable_ats(). If
> pci_enable_ats() fails, the driver still updates its internal state
> master->ats_enabled to true in arm_smmu_attach_commit().
>
> This leads to a state mismatch between the SMMU driver and the PCI core,
> the SMMU driver operates assuming ATS is enabled. Later, when detaching
> the device the driver callspci_disable_ats() because it believes ATS is
> enabled. This triggers a warning in the PCI core since ATS was never
> actually enabled on the device:
>
> [ 127.925080] ------------[ cut here ]------------
> [ 127.925084] WARNING: drivers/pci/ats.c:132 at pci_disable_ats+0x94/0xa8, CPU#42: iova_stress/12240
> [ 127.949761] Modules linked in: vfat fat dummy bridge stp llc cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd
> [ 127.961760] CPU: 42 UID: 0 PID: 12240 Comm: iova_stress Not tainted 7.1.0-smp-DEV #4 PREEMPTLAZY
> [ 127.970619] Hardware name: <REDACTED>
> [ 127.977655] pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [ 127.984603] pc : pci_disable_ats+0x94/0xa8
> [ 127.988687] lr : arm_smmu_attach_prepare+0x104/0x310
> [ 127.993641] sp : ffff8000ae013ab0
> [ 127.996943] x29: ffff8000ae013ac0 x28: ffff0001481b0000 x27: ffff000103d17980
> [ 128.004066] x26: ffff0001093aad48 x25: ffff0001093ab020 x24: ffff0001118200c8
> [ 128.011189] x23: ffffcf76ddf1ca1c x22: ffffcf76df679020 x21: ffff000148f1df00
> [ 128.018311] x20: ffff8000ae013c18 x19: ffff8000ae013b28 x18: 0000000000000000
> [ 128.025434] x17: 0000000000000000 x16: ffff00010945a358 x15: ffff000110ffd080
> [ 128.032557] x14: 0000000000000200 x13: 0000000000000002 x12: 0000000000000001
> [ 128.039679] x11: 0000000000004040 x10: 0000000000000001 x9 : ffffcf76dd37f504
> [ 128.046801] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
> [ 128.053924] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0001093ab000
> [ 128.061046] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff000111820000
> [ 128.068169] Call trace:
> [ 128.070603] pci_disable_ats+0x94/0xa8 (P)
> [ 128.074688] arm_smmu_attach_prepare+0x104/0x310
> [ 128.079292] arm_smmu_attach_dev_ste+0x128/0x1e0
> [ 128.083899] arm_smmu_attach_dev_blocked+0x50/0x88
> [ 128.088677] __iommu_attach_device+0x30/0x138
> [ 128.093026] __iommu_group_set_domain_internal+0xdc/0x228
> [ 128.098412] __iommu_take_dma_ownership+0x118/0x150
> [ 128.103278] iommu_group_claim_dma_owner+0x48/0x80
> [ 128.108056] vfio_container_attach_group+0xc8/0x1b0
> [ 128.112927] vfio_group_fops_unl_ioctl+0x578/0x968
> [ 128.117706] __arm64_sys_ioctl+0x90/0xe8
> [ 128.121622] invoke_syscall+0x50/0x108
> [ 128.125366] el0_svc_common+0x94/0xe8
> [ 128.129016] do_el0_svc+0x24/0x38
> [ 128.132319] el0_svc+0x44/0xf8
> [ 128.135364] el0t_64_sync_handler+0x68/0xe0
> [ 128.139534] el0t_64_sync+0x1b0/0x1b8
> [ 128.143185] ---[ end trace 0000000000000000 ]---
>
> The issue was exposed under heavy load when running a VFIO-based DMA map
> stress test: iova_stress [1]
>
> Fix this by propagating the error from arm_smmu_enable_ats() and updating
> state->ats_enabled to false on failure. This ensures that
> master->ats_enabled correctly reflects the actual state of the device.
>
> Signed-off-by: Pranjal Shrivastava <praan@google.com>
>
> [1] https://github.com/soleen/iova_stress
Missed the Fixes tag here, posted a v2:
https://lore.kernel.org/all/20260504163842.2692314-1-praan@google.com/
Thanks,
Praan
prev parent reply other threads:[~2026-05-04 16:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 12:53 [PATCH rc] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking Pranjal Shrivastava
2026-05-04 16:40 ` Pranjal Shrivastava [this message]
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=afjL8sUdlFCdVfno@google.com \
--to=praan@google.com \
--cc=danielmentz@google.com \
--cc=dmatlack@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=nicolinc@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=robin.murphy@arm.com \
--cc=skhawaja@google.com \
--cc=smostafa@google.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