Rust for Linux List
 help / color / mirror / Atom feed
* [PATCH] rust: workqueue: add cancel_work for Arc<T>
  2026-05-18  4:11 [PATCH 1/2] rust: workqueue: add SAFETY comments for Pin<KBox<T>> impls Moayad Salloum
@ 2026-05-18  4:11 ` Moayad Salloum
  0 siblings, 0 replies; 5+ messages in thread
From: Moayad Salloum @ 2026-05-18  4:11 UTC (permalink / raw)
  To: rust-for-linux
  Cc: linux-kernel, ojeda, aliceryhl, lossin, a.hindborg,
	Moayad Salloum

Add a safe cancel_work() function for work items owned by Arc<T>.

In the existing API, enqueueing an Arc<T> calls Arc::into_raw() to leak
the Arc reference into the workqueue. WorkItemPointer::run() is the only
place that reclaims it via Arc::from_raw(). Without a cancel function,
drivers had no safe way to cancel pending work, and any attempt to do so
by calling bindings::cancel_work() directly would leak the Arc reference
since run() would never be called.

cancel_work() handles this by calling Arc::from_raw() when cancel
succeeds, reclaiming the leaked reference that __enqueue() left behind.

Signed-off-by: Moayad Salloum <salloummoayad4@gmail.com>
---
 rust/kernel/workqueue.rs | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 6d665418b..daff9040a 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -871,6 +871,35 @@ unsafe fn __enqueue<F>(self, queue_work_on: F) -> Self::EnqueueOutput
     }
 }
 
+pub fn cancel_work<T, const ID: u64>(item: &Arc<T>) -> bool
+where
+    T: WorkItem<ID, Pointer = Arc<T>>,
+    T: HasWork<T, ID>,
+{
+    let ptr = Arc::as_ptr(item);
+    // SAFETY: `ptr` comes from `Arc::as_ptr` which is a valid non-dangling pointer to `T`.
+    let work_ptr = unsafe { T::raw_get_work(ptr.cast_mut()) };
+    // SAFETY: `raw_get_work` returns a pointer to a valid `Work<T, ID>` field.
+    let work_ptr_struct = unsafe { Work::raw_get(work_ptr) };
+    // SAFETY: The `Arc` keeps the allocation alive, so `work_ptr_struct` is valid for
+    // the duration of this call.
+    let cancel_res = unsafe { bindings::cancel_work(work_ptr_struct) };
+
+    if cancel_res {
+        // SAFETY: `cancel_work` returned true, meaning the work was pending and has been
+        // removed from the queue. The workqueue will not call `run`, so we are responsible
+        // for reclaiming the `Arc` reference that was leaked in `__enqueue` via
+        // `Arc::into_raw`. We use `work_container_of` to recover the original `*const T`
+        // pointer from the `Work<T, ID>` field pointer, then reconstruct the `Arc` with
+        // `Arc::from_raw` and drop it to decrement the ref count.
+        let item_ptr = unsafe { T::work_container_of(work_ptr) };
+        drop(unsafe { Arc::from_raw(item_ptr) });
+        true
+    } else {
+        false
+    }
+}
+
 // SAFETY: By the safety requirements of `HasDelayedWork`, the `work_struct` returned by methods in
 // `HasWork` provides a `work_struct` that is the `work` field of a `delayed_work`, and the rest of
 // the `delayed_work` has the same access rules as its `work` field.
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH] rust: workqueue: add cancel_work for Arc<T>
@ 2026-05-18  4:23 Moayad Salloum
  2026-05-18  5:45 ` Onur Özkan
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Moayad Salloum @ 2026-05-18  4:23 UTC (permalink / raw)
  To: rust-for-linux
  Cc: linux-kernel, ojeda, aliceryhl, lossin, a.hindborg,
	Moayad Salloum

Add a safe cancel_work() function for work items owned by Arc<T>.

In the existing API, enqueueing an Arc<T> calls Arc::into_raw() to leak
the Arc reference into the workqueue. WorkItemPointer::run() is the only
place that reclaims it via Arc::from_raw(). Without a cancel function,
drivers had no safe way to cancel pending work, and any attempt to do so
by calling bindings::cancel_work() directly would leak the Arc reference
since run() would never be called.

cancel_work() handles this by calling Arc::from_raw() when cancel
succeeds, reclaiming the leaked reference that __enqueue() left behind.

Signed-off-by: Moayad Salloum <salloummoayad4@gmail.com>
---
 rust/kernel/workqueue.rs | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 6d665418b..daff9040a 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -871,6 +871,35 @@ unsafe fn __enqueue<F>(self, queue_work_on: F) -> Self::EnqueueOutput
     }
 }
 
+pub fn cancel_work<T, const ID: u64>(item: &Arc<T>) -> bool
+where
+    T: WorkItem<ID, Pointer = Arc<T>>,
+    T: HasWork<T, ID>,
+{
+    let ptr = Arc::as_ptr(item);
+    // SAFETY: `ptr` comes from `Arc::as_ptr` which is a valid non-dangling pointer to `T`.
+    let work_ptr = unsafe { T::raw_get_work(ptr.cast_mut()) };
+    // SAFETY: `raw_get_work` returns a pointer to a valid `Work<T, ID>` field.
+    let work_ptr_struct = unsafe { Work::raw_get(work_ptr) };
+    // SAFETY: The `Arc` keeps the allocation alive, so `work_ptr_struct` is valid for
+    // the duration of this call.
+    let cancel_res = unsafe { bindings::cancel_work(work_ptr_struct) };
+
+    if cancel_res {
+        // SAFETY: `cancel_work` returned true, meaning the work was pending and has been
+        // removed from the queue. The workqueue will not call `run`, so we are responsible
+        // for reclaiming the `Arc` reference that was leaked in `__enqueue` via
+        // `Arc::into_raw`. We use `work_container_of` to recover the original `*const T`
+        // pointer from the `Work<T, ID>` field pointer, then reconstruct the `Arc` with
+        // `Arc::from_raw` and drop it to decrement the ref count.
+        let item_ptr = unsafe { T::work_container_of(work_ptr) };
+        drop(unsafe { Arc::from_raw(item_ptr) });
+        true
+    } else {
+        false
+    }
+}
+
 // SAFETY: By the safety requirements of `HasDelayedWork`, the `work_struct` returned by methods in
 // `HasWork` provides a `work_struct` that is the `work` field of a `delayed_work`, and the rest of
 // the `delayed_work` has the same access rules as its `work` field.
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: workqueue: add cancel_work for Arc<T>
  2026-05-18  4:23 [PATCH] rust: workqueue: add cancel_work for Arc<T> Moayad Salloum
@ 2026-05-18  5:45 ` Onur Özkan
  2026-05-18  8:10 ` kernel test robot
  2026-05-18 19:46 ` kernel test robot
  2 siblings, 0 replies; 5+ messages in thread
From: Onur Özkan @ 2026-05-18  5:45 UTC (permalink / raw)
  To: Moayad Salloum
  Cc: rust-for-linux, linux-kernel, ojeda, aliceryhl, lossin,
	a.hindborg

On Mon, 18 May 2026 07:23:47 +0300
Moayad Salloum <salloummoayad4@gmail.com> wrote:

> Add a safe cancel_work() function for work items owned by Arc<T>.
> 
> In the existing API, enqueueing an Arc<T> calls Arc::into_raw() to leak
> the Arc reference into the workqueue. WorkItemPointer::run() is the only
> place that reclaims it via Arc::from_raw(). Without a cancel function,
> drivers had no safe way to cancel pending work, and any attempt to do so
> by calling bindings::cancel_work() directly would leak the Arc reference
> since run() would never be called.
> 
> cancel_work() handles this by calling Arc::from_raw() when cancel
> succeeds, reclaiming the leaked reference that __enqueue() left behind.
> 
> Signed-off-by: Moayad Salloum <salloummoayad4@gmail.com>
> ---
>  rust/kernel/workqueue.rs | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> index 6d665418b..daff9040a 100644
> --- a/rust/kernel/workqueue.rs
> +++ b/rust/kernel/workqueue.rs
> @@ -871,6 +871,35 @@ unsafe fn __enqueue<F>(self, queue_work_on: F) -> Self::EnqueueOutput
>      }
>  }
>  
> +pub fn cancel_work<T, const ID: u64>(item: &Arc<T>) -> bool
> +where
> +    T: WorkItem<ID, Pointer = Arc<T>>,
> +    T: HasWork<T, ID>,
> +{
> +    let ptr = Arc::as_ptr(item);
> +    // SAFETY: `ptr` comes from `Arc::as_ptr` which is a valid non-dangling pointer to `T`.
> +    let work_ptr = unsafe { T::raw_get_work(ptr.cast_mut()) };
> +    // SAFETY: `raw_get_work` returns a pointer to a valid `Work<T, ID>` field.
> +    let work_ptr_struct = unsafe { Work::raw_get(work_ptr) };
> +    // SAFETY: The `Arc` keeps the allocation alive, so `work_ptr_struct` is valid for
> +    // the duration of this call.
> +    let cancel_res = unsafe { bindings::cancel_work(work_ptr_struct) };
> +
> +    if cancel_res {
> +        // SAFETY: `cancel_work` returned true, meaning the work was pending and has been
> +        // removed from the queue. The workqueue will not call `run`, so we are responsible
> +        // for reclaiming the `Arc` reference that was leaked in `__enqueue` via
> +        // `Arc::into_raw`. We use `work_container_of` to recover the original `*const T`
> +        // pointer from the `Work<T, ID>` field pointer, then reconstruct the `Arc` with
> +        // `Arc::from_raw` and drop it to decrement the ref count.
> +        let item_ptr = unsafe { T::work_container_of(work_ptr) };
> +        drop(unsafe { Arc::from_raw(item_ptr) });
> +        true
> +    } else {
> +        false
> +    }
> +}
> +
>  // SAFETY: By the safety requirements of `HasDelayedWork`, the `work_struct` returned by methods in
>  // `HasWork` provides a `work_struct` that is the `work` field of a `delayed_work`, and the rest of
>  // the `delayed_work` has the same access rules as its `work` field.
> -- 
> 2.43.0
> 

[1] already covers this.

- Onur

[1]: https://lore.kernel.org/all/20260510082211.207450-1-work@onurozkan.dev


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: workqueue: add cancel_work for Arc<T>
  2026-05-18  4:23 [PATCH] rust: workqueue: add cancel_work for Arc<T> Moayad Salloum
  2026-05-18  5:45 ` Onur Özkan
@ 2026-05-18  8:10 ` kernel test robot
  2026-05-18 19:46 ` kernel test robot
  2 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2026-05-18  8:10 UTC (permalink / raw)
  To: Moayad Salloum, rust-for-linux
  Cc: oe-kbuild-all, linux-kernel, ojeda, aliceryhl, lossin, a.hindborg,
	Moayad Salloum

Hi Moayad,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rust/rust-next]
[also build test WARNING on next-20260508]
[cannot apply to linus/master v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Moayad-Salloum/rust-workqueue-add-cancel_work-for-Arc-T/20260518-122747
base:   https://github.com/Rust-for-Linux/linux rust-next
patch link:    https://lore.kernel.org/r/20260518042347.95213-1-salloummoayad4%40gmail.com
patch subject: [PATCH] rust: workqueue: add cancel_work for Arc<T>
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260518/202605181046.7pBrngJZ-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260518/202605181046.7pBrngJZ-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605181046.7pBrngJZ-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> warning: missing documentation for a function
   --> rust/kernel/workqueue.rs:874:1
   |
   874 | / pub fn cancel_work<T, const ID: u64>(item: &Arc<T>) -> bool
   875 | | where
   876 | |     T: WorkItem<ID, Pointer = Arc<T>>,
   877 | |     T: HasWork<T, ID>,
   | |______________________^
   |
   = note: requested on the command line with `-W missing-docs`

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: workqueue: add cancel_work for Arc<T>
  2026-05-18  4:23 [PATCH] rust: workqueue: add cancel_work for Arc<T> Moayad Salloum
  2026-05-18  5:45 ` Onur Özkan
  2026-05-18  8:10 ` kernel test robot
@ 2026-05-18 19:46 ` kernel test robot
  2 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2026-05-18 19:46 UTC (permalink / raw)
  To: Moayad Salloum, rust-for-linux
  Cc: llvm, oe-kbuild-all, linux-kernel, ojeda, aliceryhl, lossin,
	a.hindborg, Moayad Salloum

Hi Moayad,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rust/rust-next]
[also build test WARNING on linus/master v7.1-rc4 next-20260518]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Moayad-Salloum/rust-workqueue-add-cancel_work-for-Arc-T/20260518-122747
base:   https://github.com/Rust-for-Linux/linux rust-next
patch link:    https://lore.kernel.org/r/20260518042347.95213-1-salloummoayad4%40gmail.com
patch subject: [PATCH] rust: workqueue: add cancel_work for Arc<T>
config: x86_64-randconfig-011-20260518 (https://download.01.org/0day-ci/archive/20260519/202605190332.rlkguvbn-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605190332.rlkguvbn-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605190332.rlkguvbn-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> warning: missing documentation for a function
   --> rust/kernel/workqueue.rs:874:1
   |
   874 | / pub fn cancel_work<T, const ID: u64>(item: &Arc<T>) -> bool
   875 | | where
   876 | |     T: WorkItem<ID, Pointer = Arc<T>>,
   877 | |     T: HasWork<T, ID>,
   | |______________________^
   |
   = note: requested on the command line with `-W missing-docs`

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-05-18 19:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-18  4:23 [PATCH] rust: workqueue: add cancel_work for Arc<T> Moayad Salloum
2026-05-18  5:45 ` Onur Özkan
2026-05-18  8:10 ` kernel test robot
2026-05-18 19:46 ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2026-05-18  4:11 [PATCH 1/2] rust: workqueue: add SAFETY comments for Pin<KBox<T>> impls Moayad Salloum
2026-05-18  4:11 ` [PATCH] rust: workqueue: add cancel_work for Arc<T> Moayad Salloum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox