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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH5fLgj6Wnrn6Ois+MbX16j2szRsBEgqVyArcGwhjEK52JnD3Q@mail.gmail.com>
Date: Wed, 15 Jan 2025 15:42:44 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boqun Feng <boqun.feng@...il.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 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*
references to it than the workqueue.

Alice