Re: [PATCH v2 1/1] rust: add Work::disable_sync

[Onur Özkan]

On Mon, 04 May 2026 07:54:54 +0000
Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:

> On Fri, May 01, 2026 at 10:11:22PM +0300, Onur Özkan wrote:
> > Adds Work::disable_sync() as a safe wrapper for disable_work_sync().
> > 
> > Drivers can use this during teardown to stop new queueing and wait for
> > queued or running work to finish before dropping related resources.
> > 
> > Signed-off-by: Onur Özkan <work@xxxxxxxxxxxxx>
> > ---
> >  rust/kernel/workqueue.rs | 121 ++++++++++++++++++++++++++-------------
> >  1 file changed, 81 insertions(+), 40 deletions(-)
> > 
> > diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> > index 7e253b6f299c..d0f9b4ba7f27 100644
> > --- a/rust/kernel/workqueue.rs
> > +++ b/rust/kernel/workqueue.rs
> > @@ -267,7 +267,7 @@ pub unsafe fn from_raw<'a>(ptr: *const bindings::workqueue_struct) -> &'a Queue
> >  
> >      /// Enqueues a work item.
> >      ///
> > -    /// This may fail if the work item is already enqueued in a workqueue.
> > +    /// This may fail if the work item is already enqueued in a workqueue or disabled.
> >      ///
> >      /// The work item will be submitted using `WORK_CPU_UNBOUND`.
> >      pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
> 
> Can you elaborate on the case where disable leads to failure here? Can
> you not enqueue a work item again after disabling it? Is there a doc
> test illustrating this case that I can run for myself to see the
> behavior in action?

As we discussed on yesterday's call, I looked into cancel_work_sync and
it seems we can make this work in the tyr reset implementation. We already
store an atomic reset state, it can be used to prevent future enqueues in
reset scheduling.

I will send a patch for the cancel_sync function soon.

Thanks,
Onur

> 
> Alice