netdev - Re: [PATCH net-next v4 3/6] rust: net::phy implement AsRef<kernel::device::Device> trait

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: <c2002c1b-9e01-4d4f-8426-8baa49614786@proton.me>
Date: Sun, 18 Aug 2024 16:19:39 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Andrew Lunn <andrew@...n.ch>
Cc: Greg KH <gregkh@...uxfoundation.org>, FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com, aliceryhl@...gle.com
Subject: Re: [PATCH net-next v4 3/6] rust: net::phy implement AsRef<kernel::device::Device> trait

On 18.08.24 18:16, Andrew Lunn wrote:
>> Thanks that's good to know.
>>
>>>> So i have to wounder if you are solving this at the correct
>>>> level. This should be generic to any device, so the Rust concept of a
>>>> device should be stating these guarantees, not each specific type of
>>>> device.
>>>
>>> It should, why isn't it using the rust binding to Device that we already
>>> have:
>>> 	https://rust.docs.kernel.org/kernel/device/struct.Device.html
>>> or is it?  I'm confused now...
>>
>> It is using that one.
>> I wanted to verify that we can use that one, since using this
>> implementation users can freely increment the refcount of the device
>> (without decrementing it before control is given back to PHYLIB). Since
>> that seems to be the case, all is fine.
> 
> Any driver which is not using the device core is broken, and no amount
> of SAFETY is going to fix it.

This is what I did not know, and I asked to ensure that we don't
introduce miscommunication with the C side. (i.e. can we rely
in our SAFETY comments that devices are always used in this way)

---
Cheers,
Benno