linux-kernel - Re: [PATCH v6] rust: iommu: 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] [day] [month] [year] [list]

Message-ID: <CAH5fLgixtTyrRcHE6i5RWE3_DgeY59b4B81gF4iDEu1shT_ikw@mail.gmail.com>
Date: Sun, 18 Jan 2026 22:26:42 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Gary Guo <gary@...yguo.net>
Cc: Joerg Roedel <joro@...tes.org>, Miguel Ojeda <ojeda@...nel.org>, Will Deacon <will@...nel.org>, 
	Daniel Almeida <daniel.almeida@...labora.com>, 
	Boris Brezillon <boris.brezillon@...labora.com>, Robin Murphy <robin.murphy@....com>, 
	Jason Gunthorpe <jgg@...pe.ca>, Boqun Feng <boqun.feng@...il.com>, 
	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>, 
	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, 
	Deborah Brouwer <deborah.brouwer@...labora.com>
Subject: Re: [PATCH v6] rust: iommu: add io_pgtable abstraction

On Sun, Jan 18, 2026 at 4:57 PM Gary Guo <gary@...yguo.net> wrote:
>
> On Sun Jan 18, 2026 at 10:08 AM GMT, Alice Ryhl wrote:
> > +// For the initial users of these rust bindings, the GPU FW is managing the IOTLB and performs all
> > +// required invalidations using a range. There is no need for it get ARM style invalidation
> > +// instructions from the page table code.
> > +//
> > +// Support for flushing the TLB with ARM style invalidation instructions may be added in the
> > +// future.
> > +static NOOP_FLUSH_OPS: bindings::iommu_flush_ops = bindings::iommu_flush_ops {
> > +    tlb_flush_all: Some(rust_tlb_flush_all_noop),
> > +    tlb_flush_walk: Some(rust_tlb_flush_walk_noop),
> > +    tlb_add_page: None,
> > +};
> > +
> > +#[no_mangle]
> > +extern "C" fn rust_tlb_flush_all_noop(_cookie: *mut core::ffi::c_void) {}
>
> Any reason that these needs to be `#[no_mangle]`? Would just `extern "C"` not be
> enough? If there is a good reason, I think this should be noted as such (note
> that `#[no_mangle]` would be unsafe in edition 2024 so we probably would want to
> avoid using it if possible.

No, it's not required because these are referenced only via function
pointers stored in NOOP_FLUSH_OPS. In principle #[no_mangle] may be
removed here.

However, keeping it doesn't hurt either. There's no particular risk of
overlap with other symbols of the same name. I won't send another
version just for this. Joerg may remove it if he cares, but I don't
think it's a big deal.

> The rest LGTM, so
>
> Reviewed-by: Gary Guo <gary@...yguo.net>

Thanks for the review!

Alice