[PATCH v8 06/31] workqueue: introduce `__INIT_WORK_WITH_KEY`

Miguel Ojeda posted 31 patches 3 years, 8 months ago
There is a newer version of this series
[PATCH v8 06/31] workqueue: introduce `__INIT_WORK_WITH_KEY`
Posted by Miguel Ojeda 3 years, 8 months ago
From: Wedson Almeida Filho <wedsonaf@google.com>

A Rust helper (introduced in a later patch) needs to call
`__INIT_WORK` with a passed key, rather than define one in place.

In order to do that, this moves the initialization code from
the `__INIT_WORK` macro into a new `__INIT_WORK_WITH_KEY` macro
which takes the key as an extra parameter.

Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 include/linux/workqueue.h | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 62e75dd40d9a..06c24805e666 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -221,24 +221,31 @@ static inline unsigned int work_static(struct work_struct *work) { return 0; }
  * to generate better code.
  */
 #ifdef CONFIG_LOCKDEP
+#define __INIT_WORK_WITH_KEY(_work, _func, _onstack, _key)		\
+	do {								\
+		__init_work((_work), _onstack);				\
+		(_work)->data = (atomic_long_t) WORK_DATA_INIT();	\
+		lockdep_init_map(&(_work)->lockdep_map, "(work_completion)"#_work, _key, 0); \
+		INIT_LIST_HEAD(&(_work)->entry);			\
+		(_work)->func = (_func);				\
+	} while (0)
+
 #define __INIT_WORK(_work, _func, _onstack)				\
 	do {								\
 		static struct lock_class_key __key;			\
-									\
-		__init_work((_work), _onstack);				\
-		(_work)->data = (atomic_long_t) WORK_DATA_INIT();	\
-		lockdep_init_map(&(_work)->lockdep_map, "(work_completion)"#_work, &__key, 0); \
-		INIT_LIST_HEAD(&(_work)->entry);			\
-		(_work)->func = (_func);				\
+		__INIT_WORK_WITH_KEY(_work, _func, _onstack, &__key);	\
 	} while (0)
 #else
-#define __INIT_WORK(_work, _func, _onstack)				\
+#define __INIT_WORK_WITH_KEY(_work, _func, _onstack, _key)		\
 	do {								\
 		__init_work((_work), _onstack);				\
 		(_work)->data = (atomic_long_t) WORK_DATA_INIT();	\
 		INIT_LIST_HEAD(&(_work)->entry);			\
 		(_work)->func = (_func);				\
 	} while (0)
+
+#define __INIT_WORK(_work, _func, _onstack)				\
+	__INIT_WORK_WITH_KEY(_work, _func, _onstack, NULL)
 #endif
 
 #define INIT_WORK(_work, _func)						\
-- 
2.37.1
Re: [PATCH v8 06/31] workqueue: introduce `__INIT_WORK_WITH_KEY`
Posted by Tejun Heo 3 years, 7 months ago
On Tue, Aug 02, 2022 at 03:49:53AM +0200, Miguel Ojeda wrote:
> From: Wedson Almeida Filho <wedsonaf@google.com>
> 
> A Rust helper (introduced in a later patch) needs to call
> `__INIT_WORK` with a passed key, rather than define one in place.
> 
> In order to do that, this moves the initialization code from
> the `__INIT_WORK` macro into a new `__INIT_WORK_WITH_KEY` macro
> which takes the key as an extra parameter.
> 
> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
> Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Acked-by: Tejun Heo <tj@kernel.org>

Please feel free to route the patch with the rest of the series or let me
know if you want through the wq tree.

Thanks.

-- 
tejun
Re: [PATCH v8 06/31] workqueue: introduce `__INIT_WORK_WITH_KEY`
Posted by Miguel Ojeda 3 years, 7 months ago
Hi Tejun,

On Mon, Aug 15, 2022 at 11:14 PM Tejun Heo <tj@kernel.org> wrote:
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> Please feel free to route the patch with the rest of the series or let me
> know if you want through the wq tree.

Since for v9 [1] I had to trim the patch series, this patch is not in
the series anymore, so I think this one should ideally go through the
wq tree later on when we send it together with the Rust abstractions
for it after the core support is merged.

Thanks a lot!

[1] https://lore.kernel.org/lkml/20220805154231.31257-1-ojeda@kernel.org/

Cheers,
Miguel