Messages in this thread |  | | Date | Mon, 4 May 2026 07:54:54 +0000 | | Subject | Re: [PATCH v2 1/1] rust: add Work::disable_sync | | From | Alice Ryhl <> |
| |
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@onurozkan.dev> > --- > 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?
Alice
|  |