linux-kernel - Re: [PATCH v2] 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: <42820306-3a94-4c47-be9b-c3f89de34866@gmail.com>
Date: Thu, 15 May 2025 19:17:05 +0200
From: Christian Schrefl <chrisi.schrefl@...il.com>
To: Daniel Almeida <daniel.almeida@...labora.com>,
 Alice Ryhl <aliceryhl@...gle.com>
Cc: Boqun Feng <boqun.feng@...il.com>, ojeda@...nel.org,
 alex.gaynor@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
 benno.lossin@...ton.me, a.hindborg@...nel.org, tmgross@...ch.edu,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: irq: add support for request_irq()

Hi Daniel

On 14.05.25 4:44 PM, Daniel Almeida wrote:
> Hi Alice,
> 
>> On 23 Jan 2025, at 06:07, Alice Ryhl <aliceryhl@...gle.com> wrote:
>>
>> On Thu, Jan 23, 2025 at 8:18 AM Boqun Feng <boqun.feng@...il.com> wrote:
>>>
>>> On Wed, Jan 22, 2025 at 01:39:30PM -0300, Daniel Almeida wrote:
>>>> Add support for registering IRQ handlers in Rust.
>>>>
>>>> IRQ handlers are extensively used in drivers when some peripheral wants to
>>>> obtain the CPU attention. Registering a handler will make the system invoke the
>>>> passed-in function whenever the chosen IRQ line is triggered.
>>>>
>>>> Both regular and threaded IRQ handlers are supported through a Handler (or
>>>> ThreadedHandler) trait that is meant to be implemented by a type that:
>>>>
>>>> a) provides a function to be run by the system when the IRQ fires and,
>>>>
>>>> b) holds the shared data (i.e.: `T`) between process and IRQ contexts.
>>>>
>>>> The requirement that T is Sync derives from the fact that handlers might run
>>>> concurrently with other processes executing the same driver, creating the
>>>> potential for data races.
>>>>
>>>> Ideally, some interior mutability must be in place if T is to be mutated. This
>>>> should usually be done through the in-flight SpinLockIrq type.
>>>>
>>>> Co-developed-by: Alice Ryhl <aliceryhl@...gle.com>
>>>> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
>>>> Signed-off-by: Daniel Almeida <daniel.almeida@...labora.com>
>>>> ---
>>>>
>>>> Changes from v1:
>>>>
>>>> - Added Co-developed-by tag to account for the work that Alice did in order to
>>>> figure out how to do this without Opaque<T> (Thanks!)
>>>> - Removed Opaque<T> in favor of plain T
>>>
>>> Hmmm...
>>>
>>> [...]
>>>
>>>> +#[pin_data(PinnedDrop)]
>>>> +pub struct Registration<T: Handler> {
>>>> +    irq: u32,
>>>> +    #[pin]
>>>> +    handler: T,
>>>
>>> I think you still need to make `handler` as `!Unpin` because compilers
>>> can assume a `&mut T` from a `Pin<&mut Registration>`, am I missing
>>> something here?
>>
>> The current version operates under the assumption that PhantomPinned
>> is enough. But I'm happy to add Aliased here.
>>
>> Alice
> 
> Aliased? What is this? I can’t find that trait or type anywhere.

Aliased was a name previously considered for `UnsafePinned` [0].
I believe that was what Alice referred to here.

Just marking the type as !Unpin should be fine on current
Rust versions, but on some future rust versions `UnsafePinned`
might be the only way to make this sound.

[0]: https://lore.kernel.org/rust-for-linux/D9VBVURZLSNT.4BTQQ8UCTGPJ@kernel.org/

Cheers
Christian