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 09:28:34 -0300 [thread overview]
Message-ID: <20250429122834.GA2260621@ziepe.ca> (raw)
In-Reply-To: <20250428205619.227835-4-robdclark@gmail.com>
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.
Jason
next prev parent reply other threads:[~2025-04-29 12:30 UTC|newest]
Thread overview: 7+ 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 03/33] iommu/io-pgtable-arm: Add quirk to quiet WARN_ON() Rob Clark
2025-04-29 12:28 ` Jason Gunthorpe [this message]
2025-04-29 13:58 ` Rob Clark
2025-04-29 14:05 ` Jason Gunthorpe
2025-04-29 12:38 ` Robin Murphy
2025-04-29 13:59 ` 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=20250429122834.GA2260621@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