From: "Gary Guo" <gary@garyguo.net>
To: aakash.bollineni@multicorewareinc.com,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn.roy.baron@gmail.com>,
"Alice Ryhl" <aliceryhl@google.com>, "Tejun Heo" <tj@kernel.org>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
"Boqun Feng" <boqun@kernel.org>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>
Cc: <rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] rust: helpers: add workqueue helpers
Date: Tue, 07 Apr 2026 13:48:30 +0100 [thread overview]
Message-ID: <DHMXNMLMMVDR.3E3J1SYEH8EKF@garyguo.net> (raw)
In-Reply-To: <20260407-workqueue-v3-final-v4-1-c27da7e5f175@multicorewareinc.com>
On Tue Apr 7, 2026 at 11:37 AM BST, Aakash Bollineni via B4 Relay wrote:
> From: Aakash Bollineni <aakash.bollineni@multicorewareinc.com>
>
> Add C-helpers to bridge the Rust workqueue abstraction with the
> kernel's C workqueue macros. These helpers wrap core workqueue
> functions that are either inline or macros in C, making them
> accessible to Rust FFI.
> New wrappers:
> - rust_helper_work_pending(): Wraps work_pending().
> - rust_helper_cancel_work_sync(): Wraps cancel_work_sync().
> - rust_helper_cancel_delayed_work_sync(): Wraps cancel_delayed_work_sync().
These lines are of very low information density. Just state what's wrapped.
> - rust_helper_init_delayed_work(): Performs robust initialization of
> a delayed_work structure, ensuring the correct timer function
> (delayed_work_timer_fn) and lockdep maps are initialized using
> standard kernel macros.
> These helpers are essential for supporting safe cancellation and
> correct DelayedWork lifecycle management in the Rust workqueue API.
>
> Signed-off-by: Aakash Bollineni <aakash.bollineni@multicorewareinc.com>
> ---
> rust/helpers/workqueue.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/rust/helpers/workqueue.c b/rust/helpers/workqueue.c
> index ce1c3a5b2150..85a6c0b9e4d5 100644
> --- a/rust/helpers/workqueue.c
> +++ b/rust/helpers/workqueue.c
> @@ -14,3 +14,35 @@ __rust_helper void rust_helper_init_work_with_key(struct work_struct *work,
> INIT_LIST_HEAD(&work->entry);
> work->func = func;
> }
> +
> +__rust_helper bool rust_helper_work_pending(struct work_struct *work)
> +{
> + return work_pending(work);
> +}
> +
> +__rust_helper bool rust_helper_cancel_work_sync(struct work_struct *work)
> +{
> + return cancel_work_sync(work);
> +}
> +
> +__rust_helper bool rust_helper_cancel_delayed_work_sync(struct delayed_work *dwork)
> +{
> + return cancel_delayed_work_sync(dwork);
> +}
> +
> +__rust_helper void rust_helper_init_delayed_work(struct delayed_work *dwork,
> + work_func_t func,
> + const char *name,
> + struct lock_class_key *key,
> + const char *tname,
> + struct lock_class_key *tkey)
> +{
> + INIT_DELAYED_WORK(dwork, func);
This is just broken. You're initializing things multiple times.
> + lockdep_init_map(&dwork->work.lockdep_map, name, key, 0);
The two lines above can just be
rust_helper_init_work(&dwork->work, func, 0, name, key);
> + timer_init_key(&dwork->timer, dwork->timer.function, TIMER_IRQSAFE, tname, tkey);
The existing impl of INIT_DELAYED_WORK uses `delayed_work_timer_fn`.
> +}
> +
> +__rust_helper void *rust_helper_get_dwork_timer_fn(void)
> +{
> + return (void *)delayed_work_timer_fn;
Why?
> +}
next prev parent reply other threads:[~2026-04-07 12:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 10:37 [PATCH v4 0/3] rust: workqueue: add safe cancellation and status methods Aakash Bollineni via B4 Relay
2026-04-07 10:37 ` [PATCH v4 1/3] rust: helpers: add workqueue helpers Aakash Bollineni via B4 Relay
2026-04-07 12:48 ` Gary Guo [this message]
2026-04-07 10:37 ` [PATCH v4 2/3] rust: workqueue: add safe cancellation and status methods Aakash Bollineni via B4 Relay
2026-04-07 11:33 ` Onur Özkan
2026-04-07 10:37 ` [PATCH v4 3/3] rust: workqueue: add KUnit and sample stress tests Aakash Bollineni via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHMXNMLMMVDR.3E3J1SYEH8EKF@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=aakash.bollineni@multicorewareinc.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn.roy.baron@gmail.com \
--cc=boqun@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tj@kernel.org \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox