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: <03089090-6822-439b-a725-bd907b6d69ce@lunn.ch> Date: Sun, 29 Oct 2023 18:32:34 +0100 From: Andrew Lunn <andrew@...n.ch> To: FUJITA Tomonori <fujita.tomonori@...il.com> Cc: benno.lossin@...ton.me, boqun.feng@...il.com, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com, wedsonaf@...il.com Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers > The current code is fine from Rust perspective because the current > code copies phy_driver on stack and makes a reference to the copy, if > I undertand correctly. > > It's not nice to create an 500-bytes object on stack. It turned out > that it's not so simple to avoid it. Does it also copy the stack version over the 'real' version before exiting? If not, it is broken, since modifying state in phy_device is often why the driver is called. But copying the stack version is also broken, since another thread taking the phydev->lock is going to get lost from the linked list of waiters. Taking a copy of the C structure does seem very odd, to me as a C programmer. Andrew
Powered by blists - more mailing lists