linux-kernel - Re: [PATCH v3] io: add io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251128180255.GA836877@nvidia.com>
Date: Fri, 28 Nov 2025 14:02:55 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Will Deacon <will@...nel.org>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Boris Brezillon <boris.brezillon@...labora.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, Joerg Roedel <joro@...tes.org>,
	Robin Murphy <robin.murphy@....com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Asahi Lina <lina+kernel@...hilina.net>,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	iommu@...ts.linux.dev, linux-mm@...ck.org
Subject: Re: [PATCH v3] io: add io_pgtable abstraction

On Wed, Nov 12, 2025 at 10:15:00AM +0000, Alice Ryhl wrote:
> +    /// Map a physically contiguous range of pages of the same size.
> +    ///
> +    /// # Safety
> +    ///
> +    /// * This page table must not contain any mapping that overlaps with the mapping created by
> +    ///   this call.
> +    /// * If this page table is live, then the caller must ensure that it's okay to access the
> +    ///   physical address being mapped for the duration in which it is mapped.

All the iommu page table code runs with a caller provided locking
regime.

The caller must effectively hold a range lock over the IOVA it is
mapping/unmapping/iova_to_phys'ing and it is illegal to race those
three functions with overlapping IOVA.

For example the caller cannot map to IOVA A-B while unmapping C-B or
iova_to_physing(A).

This locking detail should be a safety statement.

> +// These bindings are currently designed for use by GPU drivers, which use this page table together
> +// with GPUVM. When using GPUVM, a single mapping operation may be translated into many operations

Now that we have the generic pt stuff I wonder if GPUVM should be
providing its own version of the page table implementation that
matches its semantics better.

> +// on the page table, and in that case you generally want to flush the TLB only once per GPUVM
> +// operation. Thus, do not use these callbacks as they would flush more often than needed.

This doesn't sound quite right to me, the flushing requirements are a
consequence of what flushing HW is available in the xTLB that is
caching this. The flushes generated by the common arm code match the
ARM64 architecture semantics. If the GPU has different semantics then
it can do something else, but one must be careful not to match a GPU
that is expecting ARM semantics with "do not use these callbacks"

IOW it doesn't seem right that common code would be making decisions
like this, the nature and requirements of the flushing are entirely up
to the driver binding to HW.

Jason