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 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.