[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7da93d6-b938-4558-95b2-e9d2e0194621@proton.me>
Date: Sat, 28 Oct 2023 08:35:38 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Boqun Feng <boqun.feng@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch, tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com, wedsonaf@...il.com
Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers
On 28.10.23 01:26, Boqun Feng wrote:
> On Fri, Oct 27, 2023 at 10:50:45PM +0000, Benno Lossin wrote:
> [...]
>>>
>>> Hmm... but does it mean even `set_speed()` has the similar issue?
>>>
>>> let phydev: *mut phy_device = self.0.get();
>>> unsafe { (*phydev).speed = ...; }
>>
>> No that should be fine, take a look at the MIR output of the following
>> code [1]:
>>
>> struct Foo {
>> a: usize,
>> b: usize,
>> }
>>
>> fn foo(ptr: *mut Foo) {
>> unsafe { (*ptr).b = 0; }
>> }
>>
>> fn bar(ptr: *mut Foo) {
>> unsafe { (&mut *ptr).b = 0; }
>> }
>>
>> Aside from some alignment checking, foo's MIR looks like this:
>>
>> bb1: {
>> ((*_1).1: usize) = const 0_usize;
>> return;
>> }
>>
>> And bar's MIR like this:
>>
>> bb1: {
>> _2 = &mut (*_1);
>> ((*_2).1: usize) = const 0_usize;
>> return;
>> }
>>
>> [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f7c4d87bf29a64af0acc09ff75d3716d
>>
>> So I think that is fine, but maybe Gary has something else to say about it.
>>
>
> Well when `-C opt-level=2`, they are the same:
>
> https://godbolt.org/z/hxxo75YYh
It doesn't matter what the optimizer does, `bar` is unsound in our use-case
and `foo` is fine (I think).
--
Cheers,
Benno
Powered by blists - more mailing lists