Re: [PATCH] workqueue: rust: add creation of workqueues

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Apr 16, 2025 at 12:17:48PM +0000, Alice Ryhl wrote:
...
> It looks like panthor handles this by only having a single delayed work
> item on each queue and using cancel_delayed_work_sync before calling
> destroy_workqueue.

That sounds a bit too restrictive.

> Tejun, what do you suggest? The goal of the Rust API is to make it
> impossible to accidentally trigger a UAF, so we need to design the API
> to prevent this mistake.

This is a hole in the C API, which isn't great but also not the end of the
world in C. I think it'd be best to solve this from C side rather than
working around it from rust side. e.g.:

- Have per-cpu list_head per workqueue (or system-wide).

- When queueing a delayed_work on timer, add the work item to the cpu's
  per-cpu list. This shouldn't need adding more fields to delayed_work given
  that the work part isn't being used yet. Also need to record the cpu.

- When timer expires, unlink from the per-cpu list and then do the normal
  queueing. This wil happen on the same cpu in most cases.

- Flush the lists from drain/destroy_workqueue(). If using system-wide
  per-cpu lists, we'd have to scan the lists and match the target wq.

This should be pretty cheap and we can probably enable this for everyone,
but if the overhead is noticeable, this can be an optional behavior
depending on a workqueue flag.

Thanks.

-- 
tejun