[PATCH] rust: list: Improve `List::remove()` SAFETY comments (and remove TODO)

From: Martin Nordholts

Date: Thu Oct 22 2026 - 16:56:36 EST


See the comments themselves for more details.

Signed-off-by: Martin Nordholts <enselic@xxxxxxxxx>
Suggested-by: Miguel Ojeda <ojeda@xxxxxxxxxx>
Link: https://github.com/Rust-for-Linux/linux/issues/351
---
rust/kernel/list.rs | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/rust/kernel/list.rs b/rust/kernel/list.rs
index 0f367264ee2e..24f2896feff2 100644
--- a/rust/kernel/list.rs
+++ b/rust/kernel/list.rs
@@ -599,11 +599,12 @@ pub fn pop_front(&mut self) -> Option<ListArc<T, ID>> {
///
/// `item` must not be in a different linked list (with the same id).
pub unsafe fn remove(&mut self, item: &T) -> Option<ListArc<T, ID>> {
- // SAFETY: TODO.
+ // SAFETY: The user provided a reference, and references are never dangling. Additionally,
+ // our pointer will not outlive the lifetime of the reference.
let mut item = unsafe { ListLinks::fields(T::view_links(item)) };
- // SAFETY: The user provided a reference, and reference are never dangling.
+ // SAFETY: The raw pointer is valid because we just derived it from a reference.
//
- // As for why this is not a data race, there are two cases:
+ // As for why deferencing is not a data race, there are two cases:
//
// * If `item` is not in any list, then these fields are read-only and null.
// * If `item` is in this list, then we have exclusive access to these fields since we
@@ -628,6 +629,7 @@ pub unsafe fn remove(&mut self, item: &T) -> Option<ListArc<T, ID>> {

// SAFETY: We just checked that `item` is in a list, so the caller guarantees that it
// is in this list. The pointers are in the right order.
+ // Mutating `&T` is ok, links are behind `UnsafeCell` (in `Opaque` in `ListLinks`).
Some(unsafe { self.remove_internal_inner(item, next, prev) })
} else {
None
--
2.53.0