Re: [PATCH v4] rust: list: Add unsafe for container_of

[Miguel Ojeda]

On Mon, Feb 16, 2026 at 2:17 PM Philipp Stanner <phasta@xxxxxxxxxx> wrote:
>
> Reviewed-by: Gary Guo <gary@xxxxxxxxxxx>
> Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>

Hmm... Where do these Reviewed-by's come from?

Ah, I see them now -- a copy of this patch was moved into another series:

  https://lore.kernel.org/rust-for-linux/20260203081403.68733-3-phasta@xxxxxxxxxx/

I understand it was an RFC series, and perhaps you didn't intend to
land the patch, so addressing the previous feedback wasn't important
for the patch series.

Nevertheless, a note about it would have been nice -- we weren't Cc'd
for some reason, and there was no notification about the move nor a
link to the previous version.

I see Gary and Alice pointed out feedback that I had already given
before -- that is why it is important to mention that this was not the
first version of the patch or better, mention that there was feedback
yet to be addressed. Otherwise, reviewers may end up mentioning again
the same feedback, just like it happened here.

> +                // SAFETY: The caller must guarantee that `links_field` is a valid pointer of type
> +                // ListLinks.
> +                let container = unsafe { $crate::container_of!(

> +                // SAFETY: By the same reasoning above, `links_field` is a valid pointer.
> +                let container = unsafe { $crate::container_of!(

I don't think these two comments justify the requirement of
`container_of!`, which is:

    /// # Safety
    ///
    /// The pointer passed to this macro, and the pointer returned by
this macro, must both be in
    /// bounds of the same allocation.

i.e. even if `links_field` is valid, it could still be UB.

By the way, the "Reviewed-by" tags don't really apply to the `//
SAFETY:` comments, so I would have probably dropped

To make progress to get the build fix done, and to avoid dropping
those tags, I think I will apply the fix without the comments. Then
please feel free to send the safety comments separately, which can be
iterated independently. (In fact, we may want to reorganize a bit the
safety comments within the macro...).

Sounds good to everyone?

(The formatting is also still not right -- this was pointed out by at
least a couple people now. Anyway, I will fix it myself.).

Cheers,
Miguel