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
| ||
|
Message-ID: <d7098404-e34e-4067-8d0e-778922aa15a1@proton.me> Date: Sat, 21 Oct 2023 08:01:15 +0000 From: Benno Lossin <benno.lossin@...ton.me> To: Andrew Lunn <andrew@...n.ch> Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, miguel.ojeda.sandonis@...il.com, tmgross@...ch.edu, boqun.feng@...il.com, wedsonaf@...il.com, greg@...ah.com Subject: Re: [PATCH net-next v5 1/5] rust: core abstractions for network PHY drivers On 20.10.23 21:50, Andrew Lunn wrote: >> I will try to explain things a bit more. >> >> So this case is a bit difficult to figure out, because what is >> going on is not really a pattern that is used in Rust. > > It is however a reasonably common pattern in the kernel. It stems from > driver writers often don't understand locking. So the core does the > locking, leaving the driver writers to just handle the problems of the > hardware. I have seen this pattern the first time here, I am sure more experienced members such as Miguel and Wedson have seen it before. I am not saying that it is incompatible with Rust, just that it wouldn't be done like this if it were purely Rust. > Rust maybe makes locking more of a visible issue, but if driver > writers don't understand locking, the language itself does not make > much difference. I think Rust will make a big difference: - you cannot access data protected by a lock without locking the lock beforehand. - you cannot forget to unlock a lock. >> We already have exclusive access to the `phy_device`, so in Rust >> you would not need to lock anything to also have exclusive access to the >> embedded `mii_bus`. > > I would actually say its not the PHY drivers problem at all. The > mii_bus is a property of the MDIO layers, and it is the MDIO layers > problem to impose whatever locking it needs for its properties. Since the MDIO layer would provide its own serialization, in Rust we would not protect the `mdio_device` with a lock. In this case it could just be a coincidence that both locks are locked, since IIUC `phy_device` is locked whenever callbacks are called. > Also, mii_bus is not embedded. Its a pointer to an mii_bus. The phy > lock protects the pointer. But its the MDIO layer which needs to > protect what the pointer points to. Oh I overlooked the `*`. Then it depends what type of pointer that is, is the `mii_bus` unique or is it shared? If it is shared, then Rust would also need another lock there. -- Cheers, Benno
Powered by blists - more mailing lists