All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Benno Lossin <benno.lossin@proton.me>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
	alice@ryhl.io, netdev@vger.kernel.org,
	rust-for-linux@vger.kernel.org, andrew@lunn.ch,
	tmgross@umich.edu, miguel.ojeda.sandonis@gmail.com,
	wedsonaf@gmail.com, aliceryhl@google.com
Subject: Re: [PATCH net-next v10 1/4] rust: core abstractions for network PHY drivers
Date: Tue, 12 Dec 2023 12:23:04 -0800	[thread overview]
Message-ID: <ZXjBKEBUrisSJ7Gx@boqun-archlinux> (raw)
In-Reply-To: <544015ec-52a4-4253-a064-8a2b370c06dc@proton.me>

On Tue, Dec 12, 2023 at 05:35:34PM +0000, Benno Lossin wrote:
> On 12/12/23 14:02, FUJITA Tomonori wrote:
> > On Mon, 11 Dec 2023 22:11:15 -0800
> > Boqun Feng <boqun.feng@gmail.com> wrote:
> > 
> >>>> // SAFETY: `phydev` points to valid object per the type invariant of
> >>>> // `Self`, also the following just minics what `phy_read()` does in C
> >>>> // side, which should be safe as long as `phydev` is valid.
> >>>>
> >>>> ?
> >>>
> >>> Looks ok to me but after a quick look at in-tree Rust code, I can't
> >>> find a comment like X is valid for the first argument in this C
> >>> function. What I found are comments like X points to valid memory.
> >>
> >> Hmm.. maybe "is valid" could be a confusing term, so the point is: if
> >> `phydev` is pointing to a properly maintained struct phy_device, then an
> >> open code of phy_read() should be safe. Maybe "..., which should be safe
> >> as long as `phydev` points to a valid struct phy_device" ?
> > 
> > As Alice suggested, I updated the comment. The current comment is:
> > 
> > // SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
> > // So it's just an FFI call.
> > let ret = unsafe {
> >     bindings::mdiobus_read((*phydev).mdio.bus, (*phydev).mdio.addr, regnum.into())
> > };
> 
> I still think you need to justify why `mdio.bus` is a pointer that you
> can give to `midobus_read`. After looking at the C code, it seems like
> that the pointer needs to point to a valid `struct mii_bus`.
> This *could* just be an invariant of `struct phy_device` [1], but where
> do we document that?

Yeah, it's better if we call it out in the type invariant.

> 
> We could make an exception here and treat this differently until bindgen
> can handle the `static inline` functions, but I am not so sure if we
> want to have this as a general pattern. We need to discuss this more.
> 

Agreed, here my latest suggestion was definitely a workaround.

> 
> [1]: Technically it is a combination of the following invariants:
> - the `mdio` field of `struct phy_device` is a valid `struct mido_device`
> - the `bus` field of `struct mdio_device` is a valid pointer to a valid
>   `struct mii_bus`.
> 
> > If phy_read() is called here, I assume that you are happy about the
> > above comment. The way to call mdiobus_read() here is safe because it
> > just an open code of phy_read(). Simply adding it works for you?
> > 
> > // SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
> > // So it's just an FFI call, open code of `phy_read()`.
> 
> This would be fine if we decide to go with the exception I detailed
> above. Although instead of "open code" I would write "see implementation
> of `phy_read()`".
> 

So the rationale here is the callsite of mdiobus_read() is just a
open-code version of phy_read(), so if we meet the same requirement of
phy_read(), we should be safe here. Maybe:

	"... open code of `phy_read()` with a valid phy_device pointer
	`phydev`"

?

Regards,
Boqun

> -- 
> Cheers,
> Benno
> 

  reply	other threads:[~2023-12-12 20:23 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-10 23:49 [PATCH net-next v10 0/4] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 1/4] rust: core " FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-11 19:49   ` [net-next PATCH] rust: net: phy: Correct the safety comment for impl Sync Boqun Feng
2023-12-11 20:23     ` Boqun Feng
2023-12-11 21:50     ` Alice Ryhl
2023-12-11 23:22       ` Boqun Feng
2023-12-11 23:55         ` FUJITA Tomonori
2023-12-12  9:17           ` Alice Ryhl
2023-12-12 10:36             ` FUJITA Tomonori
2023-12-11 21:46   ` [PATCH net-next v10 1/4] rust: core abstractions for network PHY drivers Alice Ryhl
2023-12-11 23:15     ` FUJITA Tomonori
2023-12-11 23:40       ` Boqun Feng
2023-12-11 23:47         ` FUJITA Tomonori
2023-12-12  0:49           ` Boqun Feng
2023-12-12  1:46             ` FUJITA Tomonori
2023-12-12  2:30               ` Boqun Feng
2023-12-12  4:04                 ` FUJITA Tomonori
2023-12-12  6:11                   ` Boqun Feng
2023-12-12 13:02                     ` FUJITA Tomonori
2023-12-12 17:35                       ` Benno Lossin
2023-12-12 20:23                         ` Boqun Feng [this message]
2023-12-12 22:40                           ` Benno Lossin
2023-12-12 23:27                             ` FUJITA Tomonori
2023-12-13  0:02                               ` Benno Lossin
2023-12-12 23:31                           ` FUJITA Tomonori
2023-12-13  0:01                             ` Benno Lossin
2023-12-12 23:01                         ` FUJITA Tomonori
2023-12-12 23:15                           ` Benno Lossin
2023-12-13 10:28                         ` Andrew Lunn
2023-12-13 12:14                           ` Benno Lossin
2023-12-13 10:24                     ` Andrew Lunn
2023-12-13 16:43                       ` Boqun Feng
2023-12-13 17:12                         ` Boqun Feng
2023-12-13 21:48                         ` Andrew Lunn
2023-12-13 23:40                           ` Benno Lossin
2023-12-13 23:51                             ` Benno Lossin
2023-12-14  9:26                             ` Andrew Lunn
2023-12-13 23:59                           ` Boqun Feng
2023-12-12 12:55                   ` Miguel Ojeda
2023-12-12  9:23       ` Alice Ryhl
2023-12-12 10:56         ` FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 2/4] rust: net::phy add module_phy_driver macro FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-12 22:52   ` Trevor Gross
2023-12-10 23:49 ` [PATCH net-next v10 3/4] MAINTAINERS: add Rust PHY abstractions for ETHERNET PHY LIBRARY FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 4/4] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-11 21:52   ` Alice Ryhl

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=ZXjBKEBUrisSJ7Gx@boqun-archlinux \
    --to=boqun.feng@gmail.com \
    --cc=alice@ryhl.io \
    --cc=aliceryhl@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.