netdev - Re: [PATCH net-next v4 1/4] rust: core abstractions for network PHY drivers

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 14 Oct 2023 23:18:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
	rust-for-linux@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
	tmgross@...ch.edu, boqun.feng@...il.com, wedsonaf@...il.com,
	greg@...ah.com
Subject: Re: [PATCH net-next v4 1/4] rust: core abstractions for network PHY
 drivers

> What about these functions?
> - resolve_aneg_linkmode
> - genphy_soft_reset
> - init_hw
> - start_aneg
> - genphy_read_status
> - genphy_update_link
> - genphy_read_lpa
> - genphy_read_abilities

If i'm understanding the discussion correctly, you want to know if
these C functions can modify the phydev structure that is passed to
them?

Yes, they all do modify it.

They also assume that phydev->lock is taken somewhere up the call
chain, so they are safe to modify the structure without worrying about
multiple threads being active.

There are some functions which currently don't modify the phydev
passed to them. However, we are pretty bad at putting on the const
attribute. I also think it would be dangerous to assume such functions
will forever not modify phydev.

	Andrew