linux-kernel - Re: [PATCH v3 1/3] rust: Introduce irq module

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: <e83779e6-76e4-4d6a-8019-ae853e508da7@proton.me>
Date: Thu, 15 Aug 2024 21:48:29 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Lyude Paul <lyude@...hat.com>, Boqun Feng <boqun.feng@...il.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, Danilo Krummrich <dakr@...hat.com>, airlied@...hat.com, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>, FUJITA Tomonori <fujita.tomonori@...il.com>, Aakash Sen Sharma <aakashsensharma@...il.com>, Valentin Obst <kernel@...entinobst.de>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/3] rust: Introduce irq module

On 15.08.24 22:31, Lyude Paul wrote:
> On Wed, 2024-08-14 at 13:17 -0700, Boqun Feng wrote:
>> On Wed, Aug 14, 2024 at 03:38:47PM -0400, Lyude Paul wrote:
>>> On Wed, 2024-08-14 at 10:35 -0700, Boqun Feng wrote:
>>>> note that `cb` is a `-> T` function, other than `-> (IrqDisabled<'a>,
>>>> T)`, so semantically, it doesn't require IRQ still disabled after
>>>> return.
>>>
>>> This was the reason I originally had us pass IrqDisabled as a reference and
>>> not a value - specifically since it seemed to make more sense to treat
>>> IrqDisabled as an object which exists throughout the lifetime of the closure
>>> regardless of whether we drop our reference to it or not - since it's a no-op.
>>>
>>
>> I haven't found a problem with `&IrqDisabled` as the closure parameter,
>> but I may miss something.
> 
> I had been asked by Benno to change it to by-value but it wasn't totally clear
> to me either what the reasoning was.

I wanted to avoid reborrows. The parameter of the closure has always
been `IrqDisabled`, but functions that required IRQs to be disabled took
`&IrqDisabled<'a>`.

---
Cheers,
Benno