From: Jason Gunthorpe <jgg@ziepe.ca>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
linux-arm-msm@vger.kernel.org,
Connor Abbott <cwabbott0@gmail.com>,
Rob Clark <robdclark@chromium.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
Nicolin Chen <nicolinc@nvidia.com>,
Kevin Tian <kevin.tian@intel.com>,
Joao Martins <joao.m.martins@oracle.com>,
"moderated list:ARM SMMU DRIVERS"
<linux-arm-kernel@lists.infradead.org>,
"open list:IOMMU SUBSYSTEM" <iommu@lists.linux.dev>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 03/33] iommu/io-pgtable-arm: Add quirk to quiet WARN_ON()
Date: Tue, 29 Apr 2025 11:05:04 -0300 [thread overview]
Message-ID: <20250429140504.GD2260621@ziepe.ca> (raw)
In-Reply-To: <CAF6AEGt+5cg1CRb4ZSm9poWhq6LGh=N2axfRyKOvKP5PNpVucg@mail.gmail.com>
On Tue, Apr 29, 2025 at 06:58:32AM -0700, Rob Clark wrote:
> On Tue, Apr 29, 2025 at 5:28 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Mon, Apr 28, 2025 at 01:54:10PM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > In situations where mapping/unmapping squence can be controlled by
> > > userspace, attempting to map over a region that has not yet been
> > > unmapped is an error. But not something that should spam dmesg.
> >
> > I think if you want to do something like that using the iommu API the
> > expectation is for the caller to do a iova_to_phys to check what is
> > mapped first? That seems kind of lame..
> >
> > Maybe page table driver should not not be doing these WARNs at all. If
> > we want to check for that the core iommu code should have the WARN_ON?
> >
> > eg iommufd already has a WARN_ON around iommu_unmap failures so having
> > one in the ARM page table is a double WARN.
> >
> > Don't really like using a quirk to change the API contract.
>
> I'd also be ok to have the WARN_ON instead in the iommu code. In the
> case where this quirk is needed, I'm using the io_pgtable helpers
> directly, not going via the iommu layer.
Yes, that was my thought
Then all the iommu_map/unmap() calls behave consistently here..
Jason
next prev parent reply other threads:[~2025-04-29 14:05 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 20:54 [PATCH v3 00/33] drm/msm: sparse / "VM_BIND" support Rob Clark
2025-04-28 20:54 ` [PATCH v3 01/33] drm/gpuvm: Don't require obj lock in destructor path Rob Clark
2025-04-28 20:54 ` [PATCH v3 02/33] drm/gpuvm: Allow VAs to hold soft reference to BOs Rob Clark
2025-04-28 20:54 ` [PATCH v3 03/33] iommu/io-pgtable-arm: Add quirk to quiet WARN_ON() Rob Clark
2025-04-29 12:28 ` Jason Gunthorpe
2025-04-29 13:58 ` Rob Clark
2025-04-29 14:05 ` Jason Gunthorpe [this message]
2025-04-29 12:38 ` Robin Murphy
2025-04-29 13:59 ` Rob Clark
2025-04-28 20:54 ` [PATCH v3 04/33] drm/msm: Rename msm_file_private -> msm_context Rob Clark
2025-04-28 20:54 ` [PATCH v3 05/33] drm/msm: Improve msm_context comments Rob Clark
2025-04-28 20:54 ` [PATCH v3 06/33] drm/msm: Rename msm_gem_address_space -> msm_gem_vm Rob Clark
2025-04-28 20:54 ` [PATCH v3 07/33] drm/msm: Remove vram carveout support Rob Clark
2025-04-28 20:54 ` [PATCH v3 08/33] drm/msm: Collapse vma allocation and initialization Rob Clark
2025-04-28 20:54 ` [PATCH v3 09/33] drm/msm: Collapse vma close and delete Rob Clark
2025-04-28 20:54 ` [PATCH v3 10/33] drm/msm: Don't close VMAs on purge Rob Clark
2025-04-28 20:54 ` [PATCH v3 11/33] drm/msm: drm_gpuvm conversion Rob Clark
2025-04-28 20:54 ` [PATCH v3 12/33] drm/msm: Convert vm locking Rob Clark
2025-04-28 20:54 ` [PATCH v3 13/33] drm/msm: Use drm_gpuvm types more Rob Clark
2025-04-28 20:54 ` [PATCH v3 14/33] drm/msm: Split out helper to get iommu prot flags Rob Clark
2025-04-28 20:54 ` [PATCH v3 15/33] drm/msm: Add mmu support for non-zero offset Rob Clark
2025-04-28 20:54 ` [PATCH v3 16/33] drm/msm: Add PRR support Rob Clark
2025-04-28 20:54 ` [PATCH v3 17/33] drm/msm: Rename msm_gem_vma_purge() -> _unmap() Rob Clark
2025-04-28 20:54 ` [PATCH v3 18/33] drm/msm: Lazily create context VM Rob Clark
2025-04-28 20:54 ` [PATCH v3 19/33] drm/msm: Add opt-in for VM_BIND Rob Clark
2025-04-28 20:54 ` [PATCH v3 20/33] drm/msm: Mark VM as unusable on GPU hangs Rob Clark
2025-04-28 20:54 ` [PATCH v3 21/33] drm/msm: Add _NO_SHARE flag Rob Clark
2025-04-28 20:54 ` [PATCH v3 22/33] drm/msm: Crashdump prep for sparse mappings Rob Clark
2025-04-28 20:54 ` [PATCH v3 23/33] drm/msm: rd dumping " Rob Clark
2025-04-28 20:54 ` [PATCH v3 24/33] drm/msm: Crashdec support for sparse Rob Clark
2025-04-28 20:54 ` [PATCH v3 25/33] drm/msm: rd dumping " Rob Clark
2025-04-28 20:54 ` [PATCH v3 26/33] drm/msm: Extract out syncobj helpers Rob Clark
2025-04-28 20:54 ` [PATCH v3 27/33] drm/msm: Use DMA_RESV_USAGE_BOOKKEEP/KERNEL Rob Clark
2025-04-28 20:54 ` [PATCH v3 28/33] drm/msm: Add VM_BIND submitqueue Rob Clark
2025-04-28 20:54 ` [PATCH v3 29/33] drm/msm: Support IO_PGTABLE_QUIRK_NO_WARN_ON Rob Clark
2025-04-28 20:54 ` [PATCH v3 30/33] drm/msm: Support pgtable preallocation Rob Clark
2025-04-28 20:54 ` [PATCH v3 31/33] drm/msm: Split out map/unmap ops Rob Clark
2025-04-28 20:54 ` [PATCH v3 32/33] drm/msm: Add VM_BIND ioctl Rob Clark
2025-04-28 20:54 ` [PATCH v3 33/33] drm/msm: Bump UAPI version Rob Clark
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=20250429140504.GD2260621@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=cwabbott0@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--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