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

[Alice Ryhl]

On Wed, Apr 16, 2025 at 9:53 PM Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> 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.:

Agreed. I think this fits on the C side.

> - 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.

My only concern is that we're executing work items *before* the
deadline they specified. There could be work items that assume this
doesn't happen? But maybe it's okay. Otherwise, what you suggest seems
reasonable enough to me.

Alice