From: Danilo Krummrich <dakr@kernel.org>
To: Tamir Duberstein <tamird@gmail.com>
Cc: Benno Lossin <benno.lossin@proton.me>,
ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
gary@garyguo.net, bjorn3_gh@protonmail.com,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
andrewjballance@gmail.com, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len()
Date: Sun, 16 Mar 2025 21:54:19 +0100 [thread overview]
Message-ID: <Z9c6e8cbdFMTT6K0@pollux> (raw)
In-Reply-To: <CAJ-ks9=b-uMCLMMKT-9emgrrUXeaA50DBSEAWjSD+uHHZu-i9Q@mail.gmail.com>
On Sun, Mar 16, 2025 at 03:30:27PM -0400, Tamir Duberstein wrote:
> On Sun, Mar 16, 2025 at 3:09 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Sun, Mar 16, 2025 at 07:59:34PM +0100, Danilo Krummrich wrote:
> > > But let's define it then; what about:
> > >
> > > "[`Vec::set_len`] takes (or kepps) ownership of all elements within the range
> > > [0; `new_len`] and abandons ownership of all values outside of this range, if
> > > any."
> > >
> > > The caller may take ownership of the abandoned elements."
> > >
> > > I'd argue that giving up ownership, while offering someone else to take it means
> > > that it implies that otherwise we'll just end up forgetting about the value.
> >
> > Btw. I'd still prefer if we could enforce that the caller has to document what
> > should happen to the abandoned value. But I acknowledge that the safety comment
> > isn't the scope for it.
> >
> > It'd be great if e.g. clippy would give us a tool to do something analogous to
> > safety comments.
> >
> > It think it would be useful to enfoce some additional safety documentation. For
> > instance, I think the kernel would much benefit if we could enforce that
> > mem::forget() must be justified with a comment, since as mentioned ina previous
> > mail, it can cause fatal bugs, for instance when used on lock guards.
>
> There are other examples; ManuallyDrop and Box::leak are two that
> immediately come to mind.
>
> But focusing on Vec::set_len again, could we return a mut slice to the
> tail when new_len < old_len? Something like:
>
> diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
> index c12844764671..e5f857d723ec 100644
> --- a/rust/kernel/alloc/kvec.rs
> +++ b/rust/kernel/alloc/kvec.rs
> @@ -191,9 +191,16 @@ pub fn len(&self) -> usize {
> /// - If `new_len` is greater than `self.len`, all elements
> within the interval
> /// [`self.len`,`new_len`) must be initialized.
> #[inline]
> - pub unsafe fn set_len(&mut self, new_len: usize) {
> + pub unsafe fn set_len(&mut self, new_len: usize) -> &mut [T] {
> debug_assert!(new_len <= self.capacity());
> - self.len = new_len;
> + let old_len = core::mem::replace(&mut self.len, new_len);
> + match old_len.checked_sub(new_len) {
> + None => &mut [],
> + Some(len) => {
> + // SAFETY: ...
> + unsafe {
> slice::from_raw_parts_mut(self.as_mut_ptr().add(new_len), len) }
> + }
> + }
> }
>
> Would that sufficiently communicate to the caller that they should
> deal with this memory?
I think that is a good idea. I'm not sure I like that this is useless when
new_len > self.len, but it also doesn't hurt too much, I guess.
Feel free to send the corresponding patch. Also, feel free to add the
corresponding comment about ownership while at it.
I'd just drop this patch then.
next prev parent reply other threads:[~2025-03-16 20:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 15:43 [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len() Danilo Krummrich
2025-03-15 15:43 ` [PATCH 2/2] rust: alloc: add missing invariant in Vec::set_len() Danilo Krummrich
2025-03-15 15:52 ` Danilo Krummrich
2025-03-15 17:44 ` Benno Lossin
2025-04-07 12:10 ` Danilo Krummrich
2025-03-15 16:06 ` [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len() Tamir Duberstein
2025-03-15 17:44 ` Benno Lossin
2025-03-15 18:36 ` Danilo Krummrich
2025-03-16 0:33 ` Tamir Duberstein
2025-03-16 9:38 ` Benno Lossin
2025-03-16 12:31 ` Danilo Krummrich
2025-03-16 12:42 ` Tamir Duberstein
2025-03-16 13:01 ` Danilo Krummrich
2025-03-16 13:13 ` Tamir Duberstein
2025-03-16 13:46 ` Danilo Krummrich
2025-03-16 17:40 ` Benno Lossin
2025-03-16 18:59 ` Danilo Krummrich
2025-03-16 19:09 ` Danilo Krummrich
2025-03-16 19:30 ` Tamir Duberstein
2025-03-16 20:54 ` Danilo Krummrich [this message]
2025-03-16 21:10 ` Tamir Duberstein
2025-03-16 21:17 ` Danilo Krummrich
2025-03-16 21:20 ` Tamir Duberstein
2025-03-16 21:52 ` Tamir Duberstein
2025-03-16 21:59 ` Danilo Krummrich
2025-03-17 9:52 ` Benno Lossin
2025-03-17 11:12 ` Danilo Krummrich
2025-03-17 14:57 ` Benno Lossin
2025-03-17 15:57 ` Danilo Krummrich
2025-03-17 16:03 ` Miguel Ojeda
2025-03-17 17:33 ` Benno Lossin
2025-03-17 18:28 ` Danilo Krummrich
2025-03-16 12:08 ` Danilo Krummrich
2025-03-17 10:36 ` Alice Ryhl
-- strict thread matches above, loose matches on Subject: below --
2025-03-17 9:46 Benno Lossin
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=Z9c6e8cbdFMTT6K0@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=andrewjballance@gmail.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox