linux-kernel - Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue

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: <20260211131015.7bf38cf9@fedora>
Date: Wed, 11 Feb 2026 13:10:15 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: "Danilo Krummrich" <dakr@...nel.org>
Cc: "Philipp Stanner" <phasta@...lbox.org>, <phasta@...nel.org>, "David
 Airlie" <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Gary Guo" <gary@...yguo.net>, "Benno Lossin"
 <lossin@...nel.org>, Christian König
 <christian.koenig@....com>, "Daniel Almeida"
 <daniel.almeida@...labora.com>, "Joel Fernandes" <joelagnelf@...dia.com>,
 <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
 <rust-for-linux@...r.kernel.org>
Subject: Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue

On Wed, 11 Feb 2026 12:19:04 +0100
"Danilo Krummrich" <dakr@...nel.org> wrote:

> On Wed Feb 11, 2026 at 12:07 PM CET, Boris Brezillon wrote:
> > I try to avoid using concepts the language I rely on is not friendly
> > with.  
> 
> It's not really a language limitation. For instance, you can implement lists the
> exact same way as they can be implemented in C. It's more that a memory safe
> list implementation is quite tricky in general.

That's what I mean by trickier to use, they are because of rust safety.
And again, that's not a case for saying "nah, rust is not a good fit, it
can't do easy-to-use-lists", but rather a good opportunity to think
twice about the containers we want to use.

> 
> Lists clearly do have their place. In this specific case, it probably doesn't
> matter too much, but in general I'd abstain from not using a list (where it is
> the best fit) just because they are tricky in getting them implemented in a
> memory safe way.

Read my other reply. I'm not saying "don't ever use a list in rust!",
I'm saying, "if there are valid alternatives, and they make things
slightly simpler, why not use these alternatives". And that's the case
here I think, especially since the C side does exactly that (using an
xarray over a list). Note how I didn't mention the list under the
JobQueue, because for that one, I'm not too sure XArray is a good fit
(jobs might be moved around between lists depending on their progress at
some point).