linux-kernel - Re: [PATCH] rust: irq: add support for request

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: <Z4fblpj57QgW_-5M@boqun-archlinux>
Date: Wed, 15 Jan 2025 08:00:22 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] rust: irq: add support for request_irq()

On Wed, Jan 15, 2025 at 03:42:44PM +0100, Alice Ryhl wrote:
> On Wed, Jan 15, 2025 at 3:39 PM Boqun Feng <boqun.feng@...il.com> wrote:
> >
> > On Wed, Jan 15, 2025 at 09:27:39AM +0100, Alice Ryhl wrote:
> > > On Wed, Jan 15, 2025 at 1:47 AM Boqun Feng <boqun.feng@...il.com> wrote:
> > > >
> > > > On Tue, Jan 14, 2025 at 03:57:57PM -0300, Daniel Almeida wrote:
> > > > >
> > > > > >
> > > > > > It's not the pin_init! stuff, but the Opaque stuff. If it fails, then
> > > > > > it runs the destructor of Opaque<T>, which does *not* run the
> > > > > > destructor of T.
> > > > > >
> > > > > > Alice
> > > > >
> > > > > This is pretty unintuitive if you take into account trivial examples like
> > > > >
> > > > > ```
> > > > > struct Foo(T)
> > > > > ```
> > > > >
> > > > > Where dropping Foo drops T.
> > > > >
> > > > > Is there any reason why dropping Opaque<T> doesn’t behave similarly?
> > > > >
> > > >
> > > > Because `Opaque` implies the value may not be initialized, it's similar
> > > > to `MaybeUninit`.
> > > >
> > > > Do you really need the `Opaque` here? C code won't touch `handler` if
> > > > I'm not missing anything.
> > >
> > > The irq callback is given access to handler, so it could touch it at any time.
> > >
> >
> > You're right it could, but would it? C code doesn't know the concrete
> > type of the handler, so what it usually does is just passing the
> > pointers to the Rust code (again).
> >
> > A similar case the `func` field in `ClosureWork`: it doesn't need to be
> > `Opaque`, although workqueue callback may access it.
> >
> > Am I missing something here? Daniel, why this has to be `Opaque`? Could
> > you explain?
> 
> It needs to be !Unpin, otherwise it's not safe for Rust to access the
> pointer. ClosureWork is not the same because there are no *other*

Could you elaborate it, maybe with an example? I asked because the data
wrapped by `handler` can only be exposed as an immutable reference to
safe Rust code, so how could Rust code access unsafely? The pointers are
always not noalias in Rust PoV. Thanks!

Regards,
Boqun

> references to it than the workqueue.
> 
> Alice