linux-kernel - Re: [PATCH v2 1/2] rust: add abstraction for struct device

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: <d74edb73-1dba-43f4-a50c-36354c39d758@redhat.com>
Date: Wed, 12 Jun 2024 16:51:42 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Boqun Feng <boqun.feng@...il.com>, Greg KH <gregkh@...uxfoundation.org>
Cc: rafael@...nel.org, mcgrof@...nel.org, russell.h.weight@...el.com,
 ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com,
 gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
 a.hindborg@...sung.com, aliceryhl@...gle.com, airlied@...il.com,
 fujita.tomonori@...il.com, pstanner@...hat.com, ajanulgu@...hat.com,
 lyude@...hat.com, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] rust: add abstraction for struct device

On 6/11/24 18:13, Boqun Feng wrote:
> On Tue, Jun 11, 2024 at 03:29:22PM +0200, Greg KH wrote:
>> On Tue, Jun 11, 2024 at 03:21:31PM +0200, Danilo Krummrich wrote:
>>> ...hence, I agree we should indeed add to the #Invariants and #Safety section
>>> that `->release` must be callable  from any thread.
>>>
>>> However, this is just theory, do we actually have cases where `device::release`
> 
> @Danilo, right, it's only theorical, but it's good to call it out since
> it's the requirement for a safe Rust abstraction.

Similar to my previous reply, if we want to call this out as safety requirement
in `Device::from_raw`, we probably want to add it to the documentation of the C
`struct device`, such that we can argue that this is an invariant of C's
`struct device`.

Otherwise we'd have to write something like:

"It must also be ensured that the `->release` function of a `struct device` can
be called from any non-atomic context. While not being officially documented this
is guaranteed by the invariant of `struct device`."

> 
>>> is not allowed to be called from any thread? If so, this would be very confusing
>>> for a reference counted type from a design point of view...
>>
>> What do you mean exactly "by any thread"?  Maybe not from interrupt
> 
> The `Send` trait here doesn't really differ between interrupt contexts
> and process contexts, so "by any thread", it includes all the contexts.
> However, we rely on klint[1] to detect context mismatch in compile time
> (it's still a WIP though). For this case, we would need to mark the
> `Device::dec_ref` function as might sleep.
> 
> Regards,
> Boqun
> 
> [1]: https://rust-for-linux.com/klint
> 
>> context, but any other normal thread (i.e. that you can sleep in), it
>> should be fine to call release() in.
>>
>> thanks,
>>
>> greg k-h
>