linux-kernel - Re: [PATCH v3] workqueue: rust: add delayed work items

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: <CAH5fLgg80eGbYQPeLtHsVqfQ4UmftUpzdhzWaah8qs5HwRhk6Q@mail.gmail.com>
Date: Mon, 14 Jul 2025 12:45:40 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Tejun Heo <tj@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Lai Jiangshan <jiangshanlai@...il.com>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Daniel Almeida <daniel.almeida@...labora.com>, Tamir Duberstein <tamird@...il.com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Benno Lossin <lossin@...nel.org>
Subject: Re: [PATCH v3] workqueue: rust: add delayed work items

On Fri, Jul 11, 2025 at 4:07 PM Danilo Krummrich <dakr@...nel.org> wrote:
>
> Hi Alice,
>
> On Fri Jul 11, 2025 at 9:59 AM CEST, Alice Ryhl wrote:
> > This patch is being sent for use in the various Rust GPU drivers that
> > are under development. It provides the additional feature of work items
> > that are executed after a delay.
>
> I thought I commented on this in a previous version already, but apparently I
> haven't (was it a different thread maybe?).
>
> For drivers, we should also support 'scoped' work items and worqueues, where
> 'scoped' means limit the lifetime to the driver being bound to a device.
>
> For better understanding, in C one would call this devm_alloc_workqueue(), which
> would guarantee that the workqueue is terminated on device unbind. Similar for
> individual work items on shared workqueues (such as the system ones), which
> would be canceled synchronously on driver unbind.
>
> This is very useful for drivers, since it allows to provide a &Device<Bound>
> within the work's callback, which allows drivers to access device resources
> safely and directly without additional overhead.

I believe that additional feature is more closely related to
https://lore.kernel.org/rust-for-linux/20250411-create-workqueue-v1-1-f7dbe7f1e05f@google.com/

Alice