[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b968d31a-b63b-4d2e-be6a-030e323aa7e0@gmail.com>
Date: Mon, 10 Feb 2025 00:54:25 -0800
From: Pyrex <economicsbat@...il.com>
To: abdiel.janulgue@...il.com
Cc: a.hindborg@...nel.org, airlied@...hat.com, alex.gaynor@...il.com,
aliceryhl@...gle.com, benno.lossin@...ton.me, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, dakr@...nel.org, daniel.almeida@...labora.com,
gary@...yguo.net, hch@....de, iommu@...ts.linux.dev, kernel@...entinobst.de,
linux-kernel@...r.kernel.org, m.szyprowski@...sung.com, ojeda@...nel.org,
robin.murphy@....com, rust-for-linux@...r.kernel.org, tmgross@...ch.edu
Subject: Re: [PATCH v8 0/2] Add dma coherent allocator abstraction
I'm nervy about the Rust code here.
- read()'s comment says it takes a snapshot, but it doesn't
- read()'s name implies it does a read, but it doesn't. It returns a
live, dangerous view
- into_parts()'s comment claims to decrement the refcount. One, it
doesn't. Two, it probably shouldn't, if it's supposed to transfer ownership.
- write() shouldn't take an immutable receiver without unsafe
- write() is unsound if used with the slice from read()
- the mutation in write() breaks read() without contradicting its
`Safety` requirements
- write() memcpys T, which isn't explicitly Copy
This doesn't have to be this unsafe. AsBytes + FromBytes implies Copy
(or at least it _should_) -- so the view could be of Cell.
Powered by blists - more mailing lists