linux-kernel - Re: [PATCH v3] rust: clist: Add support to interface with C linked lists

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2700c827-d3af-403c-857a-30324e0d8502@nvidia.com>
Date: Mon, 1 Dec 2025 17:43:09 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: John Hubbard <jhubbard@...dia.com>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 nouveau@...ts.freedesktop.org, Danilo Krummrich <dakr@...nel.org>,
 Dave Airlie <airlied@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
 Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>, bjorn3_gh@...tonmail.com,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Timur Tabi <ttabi@...dia.com>, Joel Fernandes <joel@...lfernandes.org>,
 Lyude Paul <elle@...thered-steel.dev>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Andrea Righi <arighi@...dia.com>, Philipp Stanner <phasta@...nel.org>
Subject: Re: [PATCH v3] rust: clist: Add support to interface with C linked
 lists



On 12/1/2025 5:17 PM, John Hubbard wrote:
> On 12/1/25 12:32 PM, Joel Fernandes wrote:
>> On 11/30/2025 7:34 PM, John Hubbard wrote:
>>> On 11/29/25 1:30 PM, Joel Fernandes wrote:
> ...
>>> This is sufficiently tricky that I think it needs some code to exercise it.
>>>
>>> Lately I'm not sure what to recommend, there are several choices, each with
>>> trade-offs: kunit, samples/rust, or even new DRM Rust code. Maybe the last
>>> one is especially nice, because it doesn't really have many downsides.
>>>
>>> Rather than wait for any of that, I wrote a quick samples/rust/rust_clist.rs
>>> and used it to sanity check my review findings, which are below.
>>
>> In v1, I had a samples/rust/ patch, but everyone's opinion almost unanimously
>> was this does not belong in a sample, but rather in doctests. What in the sample
>> is not supported by the current doctest? If something is missing, I think I can
>> add it in. Plus yes, DRM_BUDDY is going to be a consumer shortly.
> 
> Well, I won't contest the choice of doctests, since wiser heads than mine
> have already worked through the tradeoffs.
> 
> But for API developers, the problem with doctests is that no one has ever
> actually *run* the code. It's just a build test. And so critical bugs, such
> as the kernel crash/hang below, are missed.

You may want to read [1]. CONFIG_RUST_KERNEL_DOCTESTS are run at runtime. You
enable it and boot the kernel. The documentation clearly says "doctests get
compiled as Rust kernel objects, allowing them to run against a built kernel.".
And this is how I have run it as well.

[1] https://docs.kernel.org/rust/testing.html

This also explains why you think list_add_tail() is a noop in my patch, which it
is not.

> 
> I would humbly suggest that you build and *run* your own samples code, for
> new code that has no users yet.

Yes, I already have an internal tree running it. :) I am not sure why the
assume_init() triggered for you but not for me, I don't think has anything to do
with doctests since the doctests is in fact just rust code compiled as KUNIT tests.

> Because if you are skipping steps like this (posting the code before
> there is an actual caller), then the documentation of how to use it
> is not "just documentation" anymore--it really needs to run correctly.

No, that's the thing, these are run. You really are in the wrong here and appear
to not understand how doctests work.

> And actually, after writing the above...I still think it would be better
> to post this with its first caller (DRM_BUDDY, or BUDDY_DRM_ALUMNI, or
> however it ends up), so that we can see how it looks and behaves in
> practice.
> 
> What's the rush?

Who said anything about a rush? I am really confused by what you mean. It is
useful to post patches even if there are external dependencies to get feedback.
So this is also an invalid review comment unfortunately. There is no rush, this
is v3 now, did you miss that?

Thanks.