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: FUJITA Tomonori <fujita.tomonori@gmail.com>
Date: 2023-10-29 22:59:21
Also in: rust-for-linux

On Sun, 29 Oct 2023 09:48:41 -0700
Boqun Feng [off-list ref] wrote:
On Sun, Oct 29, 2023 at 01:21:12PM +0900, FUJITA Tomonori 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.
I had the same thought Benno brought the issue on `&`, but unfortunately
it's not true ;-) In the following code:

	let phydev = unsafe { *self.0.get() };

, semantically the *whole* `bindings::phy_device` is being read, so if
there is any modification (i.e. write) that may happen in the meanwhile,
it's data race, and data races are UB (even in C).
Benno said so? I'm not sure about the logic (whole v.s. partial). Even
if you read partially, the part might be modified by the C side during
reading.

For me, the issue is that creating &T for an object that might be
modified.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help