Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

rust: list: Add unsafe blocks for container_of and safety comments

impl_list_item_mod.rs calls container_of! without unsafe blocks at a
couple of places. Since container_of! is unsafe, the blocks are strictly
necessary.

The problem was so far not visible because the "unsafe-op-in-unsafe-fn"
check is a lint rather than a hard compiler error, and Rust suppresses
lints triggered inside of a macro from another crate.

Thus, the error becomes only visible once someone from within the kernel
crate tries to use linked lists:

error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub`
is unsafe and requires unsafe block
--> rust/kernel/lib.rs:252:29
|
252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
|
note: an unsafe function restricts its caller, but its body is safe by default
--> rust/kernel/list/impl_list_item_mod.rs:216:13
|
216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
= note: requested on the command line with `-D unsafe-op-in-unsafe-fn`
= note: this error originates in the macro `$crate::container_of` which comes
from the expansion of the macro `impl_list_item`

Therefore, add unsafe blocks to container_of! calls to fix the issue.

[ As discussed, let's fix the build for those that want to use the
macro within the `kernel` crate now and we can discuss the proper
safety comments afterwards. Thus I removed the ones from the patch.

However, we cannot just avoid the comments with `CLIPPY=1`, so I
provided placeholders for now, like we did in the past. They were
also needed for an `unsafe impl`.

While I am not happy about it, it isn't worse than the current
status (the comments were meant to be there), and at least this
shows what is missing -- our pre-existing "good first issue" [1]
may motivate new contributors to complete them properly.

Finally, I moved one of the existing safety comments one line down
so that Clippy could locate it.

Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]

- Miguel ]

Cc: stable@vger.kernel.org
Fixes: c77f85b347dd ("rust: list: remove OFFSET constants")
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260216131613.45344-3-phasta@kernel.org
[ Fixed formatting. Reworded to fix the lint suppression
explanation. Indent build error. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

authored by

Philipp Stanner and committed by
Miguel Ojeda
97b281d7 a58b8764

+16 -9
+16 -9
rust/kernel/list/impl_list_item_mod.rs
··· 84 84 // right type. 85 85 unsafe impl$(<$($generics)*>)? $crate::list::HasSelfPtr<$item_type $(, $id)?> for $self {} 86 86 87 + // SAFETY: TODO. 87 88 unsafe impl$(<$($generics)*>)? $crate::list::HasListLinks$(<$id>)? for $self { 88 89 #[inline] 89 90 unsafe fn raw_get_list_links(ptr: *mut Self) -> *mut $crate::list::ListLinks$(<$id>)? { 90 - // SAFETY: The caller promises that the pointer is not dangling. 91 91 let ptr: *mut $crate::list::ListLinksSelfPtr<$item_type $(, $id)?> = 92 + // SAFETY: The caller promises that the pointer is not dangling. 92 93 unsafe { ::core::ptr::addr_of_mut!((*ptr)$(.$field)*) }; 93 94 ptr.cast() 94 95 } ··· 218 217 // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it 219 218 // points at the field `$field` in a value of type `Self`. Thus, reversing that 220 219 // operation is still in-bounds of the allocation. 221 - $crate::container_of!(me, Self, $($field).*) 220 + unsafe { $crate::container_of!(me, Self, $($field).*) } 222 221 } 223 222 224 223 // GUARANTEES: ··· 243 242 // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it 244 243 // points at the field `$field` in a value of type `Self`. Thus, reversing that 245 244 // operation is still in-bounds of the allocation. 246 - $crate::container_of!(me, Self, $($field).*) 245 + unsafe { $crate::container_of!(me, Self, $($field).*) } 247 246 } 248 247 } 249 248 )*}; ··· 271 270 // SAFETY: The caller promises that `me` points at a valid value of type `Self`. 272 271 let links_field = unsafe { <Self as $crate::list::ListItem<$num>>::view_links(me) }; 273 272 274 - let container = $crate::container_of!( 275 - links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner 276 - ); 273 + // SAFETY: TODO. 274 + let container = unsafe { 275 + $crate::container_of!( 276 + links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner 277 + ) 278 + }; 277 279 278 280 // SAFETY: By the same reasoning above, `links_field` is a valid pointer. 279 281 let self_ptr = unsafe { ··· 323 319 // `ListArc` containing `Self` until the next call to `post_remove`. The value cannot 324 320 // be destroyed while a `ListArc` reference exists. 325 321 unsafe fn view_value(links_field: *mut $crate::list::ListLinks<$num>) -> *const Self { 326 - let container = $crate::container_of!( 327 - links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner 328 - ); 322 + // SAFETY: TODO. 323 + let container = unsafe { 324 + $crate::container_of!( 325 + links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner 326 + ) 327 + }; 329 328 330 329 // SAFETY: By the same reasoning above, `links_field` is a valid pointer. 331 330 let self_ptr = unsafe {