From: Boqun Feng <boqun.feng@gmail.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: benno.lossin@proton.me, andrew@lunn.ch, netdev@vger.kernel.org,
rust-for-linux@vger.kernel.org, tmgross@umich.edu,
miguel.ojeda.sandonis@gmail.com, wedsonaf@gmail.com
Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers
Date: Sun, 29 Oct 2023 11:09:17 -0700 [thread overview]
Message-ID: <ZT6fzfV9GUQOZnlx@boqun-archlinux> (raw)
In-Reply-To: <ZT6M6WPrCaLb-0QO@Boquns-Mac-mini.home>
On Sun, Oct 29, 2023 at 09:48:41AM -0700, Boqun Feng wrote:
> On Sun, Oct 29, 2023 at 01:21:12PM +0900, FUJITA Tomonori wrote:
> [...]
> >
> > 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).
>
> So both implementations have the problem because of the same cause.
>
> > It's not nice to create an 500-bytes object on stack. It turned out
> > that it's not so simple to avoid it.
>
> As you can see, copying is not the way to work around this.
>
An temporary solution is doing the #2 option from Benno, but in Rust and
open code it, like the following:
diff --git a/rust/kernel/net/phy.rs b/rust/kernel/net/phy.rs
index 145d0407fe31..f5230ac48014 100644
--- a/rust/kernel/net/phy.rs
+++ b/rust/kernel/net/phy.rs
@@ -121,10 +121,10 @@ pub fn state(&self) -> DeviceState {
///
/// It returns true if the link is up.
pub fn is_link_up(&self) -> bool {
- const LINK_IS_UP: u32 = 1;
+ const LINK_IS_UP: u64 = 1;
// SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
- let phydev = unsafe { *self.0.get() };
- phydev.link() == LINK_IS_UP
+ let bit_field = unsafe { &(*self.0.get())._bitfield_1 };
+ bit_field.get(14, 1) == LINK_IS_UP
}
/// Gets the current auto-negotiation configuration.
@@ -132,18 +132,18 @@ pub fn is_link_up(&self) -> bool {
/// It returns true if auto-negotiation is enabled.
pub fn is_autoneg_enabled(&self) -> bool {
// SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
- let phydev = unsafe { *self.0.get() };
- phydev.autoneg() == bindings::AUTONEG_ENABLE
+ let bit_field = unsafe { &(*self.0.get())._bitfield_1 };
+ bit_field.get(13, 1) == bindings::AUTONEG_ENABLE as u64
}
/// Gets the current auto-negotiation state.
///
/// It returns true if auto-negotiation is completed.
pub fn is_autoneg_completed(&self) -> bool {
- const AUTONEG_COMPLETED: u32 = 1;
+ const AUTONEG_COMPLETED: u64 = 1;
// SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
- let phydev = unsafe { *self.0.get() };
- phydev.autoneg_complete() == AUTONEG_COMPLETED
+ let bit_field = unsafe { &(*self.0.get())._bitfield_1 };
+ bit_field.get(15, 1) == AUTONEG_COMPLETED
}
/// Sets the speed of the PHY.
Of course, it's not maintainable in longer term since it relies on
hard-coding the bit offset of these bit fields. But I think it's best we
can do from Linux kernel side. It's up to Andrew and Miguel whether this
temporary solution is OK.
Regards,
Boqun
next prev parent reply other threads:[~2023-10-29 18:10 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 0:10 [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-10-26 0:10 ` [PATCH net-next v7 1/5] rust: core " FUJITA Tomonori
2023-10-27 19:09 ` Boqun Feng
2023-10-28 10:00 ` FUJITA Tomonori
2023-10-27 19:59 ` Boqun Feng
2023-10-27 21:19 ` Benno Lossin
2023-10-27 22:21 ` Boqun Feng
2023-10-27 22:36 ` Andrew Lunn
2023-10-27 22:50 ` Benno Lossin
2023-10-27 23:26 ` Boqun Feng
2023-10-27 23:52 ` Boqun Feng
2023-10-28 8:35 ` Benno Lossin
2023-10-27 22:40 ` Andrew Lunn
2023-10-28 15:16 ` Miguel Ojeda
2023-10-28 18:18 ` Andrew Lunn
2023-10-28 9:27 ` FUJITA Tomonori
2023-10-28 14:53 ` Andrew Lunn
2023-10-28 16:09 ` FUJITA Tomonori
2023-10-28 16:39 ` Benno Lossin
2023-10-28 19:06 ` Boqun Feng
2023-10-28 19:23 ` Andrew Lunn
2023-10-28 23:26 ` Boqun Feng
2023-10-28 16:37 ` Benno Lossin
2023-10-28 18:23 ` Andrew Lunn
2023-10-28 18:45 ` Benno Lossin
2023-10-29 4:21 ` FUJITA Tomonori
2023-10-29 16:48 ` Boqun Feng
2023-10-29 18:09 ` Boqun Feng [this message]
2023-10-29 18:26 ` Boqun Feng
2023-10-29 19:39 ` Andrew Lunn
2023-10-30 12:07 ` Miguel Ojeda
2023-10-30 12:32 ` Andrew Lunn
2023-10-29 22:58 ` FUJITA Tomonori
2023-10-30 0:19 ` Boqun Feng
2023-10-30 8:34 ` Benno Lossin
2023-10-30 12:49 ` FUJITA Tomonori
2023-10-30 16:45 ` Benno Lossin
2023-11-08 10:46 ` FUJITA Tomonori
2023-11-10 13:26 ` Andrew Lunn
2023-10-29 17:32 ` Andrew Lunn
2023-10-30 8:37 ` Benno Lossin
2023-10-30 11:22 ` Miguel Ojeda
2023-11-17 9:39 ` Alice Ryhl
2023-11-17 13:34 ` Andrew Lunn
2023-11-17 15:42 ` Alice Ryhl
2023-11-17 16:28 ` Andrew Lunn
2023-11-17 18:27 ` Alice Ryhl
2023-11-21 12:47 ` FUJITA Tomonori
2023-11-17 9:39 ` Alice Ryhl
2023-11-17 13:53 ` Andrew Lunn
2023-11-17 19:50 ` Greg KH
2023-11-17 23:28 ` Boqun Feng
2023-11-18 15:32 ` Andrew Lunn
2023-11-18 15:54 ` Boqun Feng
2023-11-19 11:06 ` Trevor Gross
2023-11-21 2:13 ` FUJITA Tomonori
2023-11-22 18:16 ` Boqun Feng
2023-11-19 13:51 ` FUJITA Tomonori
2023-11-19 16:08 ` Andrew Lunn
2023-10-26 0:10 ` [PATCH net-next v7 2/5] rust: net::phy add module_phy_driver macro FUJITA Tomonori
2023-11-17 9:39 ` Alice Ryhl
2023-11-19 10:50 ` FUJITA Tomonori
2023-11-19 10:54 ` Benno Lossin
2023-11-17 22:21 ` Boqun Feng
2023-11-17 22:54 ` Andrew Lunn
2023-11-17 23:01 ` Benno Lossin
2023-11-17 23:18 ` Andrew Lunn
2023-11-19 9:41 ` FUJITA Tomonori
2023-11-19 9:25 ` FUJITA Tomonori
2023-11-19 15:50 ` Andrew Lunn
2023-11-20 13:54 ` FUJITA Tomonori
2023-11-20 14:13 ` Andrew Lunn
2023-11-21 0:49 ` FUJITA Tomonori
2023-11-19 9:44 ` FUJITA Tomonori
2023-10-26 0:10 ` [PATCH net-next v7 3/5] rust: add second `bindgen` pass for enum exhaustiveness checking FUJITA Tomonori
2023-10-26 11:02 ` Miguel Ojeda
2023-10-26 11:54 ` FUJITA Tomonori
2023-10-26 12:22 ` Miguel Ojeda
2023-10-27 0:07 ` Andrew Lunn
2023-10-27 10:50 ` Miguel Ojeda
2023-10-26 0:10 ` [PATCH net-next v7 4/5] MAINTAINERS: add Rust PHY abstractions for ETHERNET PHY LIBRARY FUJITA Tomonori
2023-10-26 23:53 ` Andrew Lunn
2023-10-26 0:10 ` [PATCH net-next v7 5/5] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-11-17 9:39 ` Alice Ryhl
2023-11-19 9:57 ` FUJITA Tomonori
2023-11-19 16:03 ` Andrew Lunn
2023-11-21 6:19 ` FUJITA Tomonori
2023-11-21 7:12 ` Greg KH
2023-10-26 10:39 ` [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers Miguel Ojeda
2023-10-26 23:48 ` Andrew Lunn
2023-10-27 2:06 ` Boqun Feng
2023-10-27 2:47 ` Andrew Lunn
2023-10-27 3:11 ` Boqun Feng
2023-10-27 4:26 ` Boqun Feng
2023-10-27 14:26 ` Andrew Lunn
2023-10-27 16:41 ` Miguel Ojeda
2023-10-27 13:00 ` Andrew Lunn
2023-10-27 10:22 ` Miguel Ojeda
2023-10-27 13:09 ` Andrew Lunn
2023-10-27 10:21 ` Miguel Ojeda
2023-10-27 14:26 ` Jakub Kicinski
2023-10-27 16:36 ` Miguel Ojeda
2023-10-27 22:55 ` Andrew Lunn
2023-10-28 11:07 ` Miguel Ojeda
2023-10-28 11:41 ` Benno Lossin
2023-10-28 15:11 ` Miguel Ojeda
2023-10-28 15:00 ` Andrew Lunn
2023-10-28 15:11 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZT6fzfV9GUQOZnlx@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=andrew@lunn.ch \
--cc=benno.lossin@proton.me \
--cc=fujita.tomonori@gmail.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).