[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023101758-scone-supernova-e9a1@gregkh>
Date: Tue, 17 Oct 2023 18:15:44 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Andrew Lunn <andrew@...n.ch>,
FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, tmgross@...ch.edu,
boqun.feng@...il.com, wedsonaf@...il.com
Subject: Re: [PATCH net-next v4 1/4] rust: core abstractions for network PHY
drivers
On Tue, Oct 17, 2023 at 05:17:40PM +0200, Miguel Ojeda wrote:
> On Tue, Oct 17, 2023 at 4:32 PM Benno Lossin <benno.lossin@...ton.me> wrote:
> >
> > This is not allowed in Rust, it is UB and will lead to bad things.
>
> Yeah, and to be clear, data races are also UB in C.
And to be clear, something we totally ignore in many places in the
kernel because it flat out does not matter at all.
Think about userspace writing 2 different values to the same sysfs file
at the same time, which the kernel driver will then attempt to save into
the same location at the "same" time. Which one wins? Who cares?
Userspace did something foolish and it doesn't matter, and writes are
pretty much "atomic" in that they do not split across memory locations
so it's not a real issue.
Same here with your "speed" value, it just doesn't matter, right? One
will "win" and the other one will not, so what is the problem? Same
thing would happen if you put a lock here, but a lock would be
pointless.
So yes, I agree, mark things in rust as "mut" if you are going to change
them, that's good, but attempting to prevent multiple writes at the same
time without a lock, that's not going to matter, if it did, you would
have used a lock :)
thanks,
greg k-h
Powered by blists - more mailing lists