Thread (108 messages) 108 messages, 11 authors, 2023-11-22

Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers

From: Benno Lossin <hidden>
Date: 2023-10-30 08:37:47
Also in: rust-for-linux

On 29.10.23 18:32, Andrew Lunn wrote:
quoted
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.
It does not copy the stack version over the original. Since we only read
the `link` field in the discussed function and we hold the lock, it should
not get modified, right? So from a functional viewpoint there is no issue.
(Aside from increased stack size and the data race issue etc.)
Taking a copy of the C structure does seem very odd, to me as a C
programmer.
It is also odd in Rust.

-- 
Cheers,
Benno

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help