All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Tejun Heo <tj@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Joe Perches <joe@perches.com>, Andy Whitcroft <apw@canonical.com>,
	Dwaipayan Ray <dwaipayanray1@gmail.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>
Subject: Re: [PATCH] checkpatch: warn about flushing system-wide workqueues
Date: Thu, 5 May 2022 22:42:19 +0900	[thread overview]
Message-ID: <738afe71-2983-05d5-f0fc-d94efbdf7634@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <6e4ed62e-888b-6e7a-c13d-67656f39ca94@I-love.SAKURA.ne.jp>

On 2022/04/25 9:33, Tetsuo Handa wrote:
> On 2022/04/25 8:45, Joe Perches wrote:
>> And it's probably more readable using separate lines and it looks as
>> if the 3rd test is unnecessary as it could be combined with the 2nd.
>>
>> 		if ($line =~ /\bflush_scheduled_work\s*\(/ ||
>> 		    $line =~ /\bflush_workqueue\s*\(\s*system(_\w*)?_wq\s*\)/) {
> 
> We don't need to worry about possibility like
> 
> 	flush_workqueue(system_module1_wq);
> 
> ? Then, we can simplify like you suggested.

I initially thought that also doing static checks by scripts/checkpatch.pl
is better than only doing runtime WARN_ON(). But not all patches are checked
by scripts/checkpatch.pl . Thus, as an attempt to check without exemptions,
I now think that doing static checks via BUILD_BUG_ON() is better than
scripts/checkpatch.pl . I sent below patch to linux-next.git , and so far
it seems working (I mean, no build failure reports caused by compilers).

Subject: workqueue: Wrap flush_workqueue() using a macro

A conversion to stop flushing kernel-global workqueues is in progress.
Wrap flush_workqueue() and inject BUILD_BUG_ON() checks, in order to
prevent users who are not aware of this conversion from again start
flushing kernel-global workqueues.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 include/linux/workqueue.h | 21 +++++++++++++++++++++
 kernel/workqueue.c        |  1 +
 2 files changed, 22 insertions(+)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 7b13fae377e2e..9f78414d507c8 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -654,4 +654,25 @@ int workqueue_offline_cpu(unsigned int cpu);
 void __init workqueue_init_early(void);
 void __init workqueue_init(void);
 
+/*
+ * Detect attempt to flush system-wide workqueues at compile time when possible.
+ * See https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jp for
+ * reasons and steps for converting system-wide workqueues into local workqueues.
+ * Checks for system_wq and system_{long,unbound,highpri}_wq will be added after
+ * all in-tree users stopped flushing these workqueues.
+ */
+#define flush_workqueue(wq)						\
+({									\
+	BUILD_BUG_ON_MSG(__builtin_constant_p(&(wq) == &system_freezable_wq) &&	\
+			 &(wq) == &system_freezable_wq,			\
+			 "Please avoid flushing system_freezable_wq."); \
+	BUILD_BUG_ON_MSG(__builtin_constant_p(&(wq) == &system_power_efficient_wq) && \
+			 &(wq) == &system_power_efficient_wq,		\
+			 "Please avoid flushing system_power_efficient_wq."); \
+	BUILD_BUG_ON_MSG(__builtin_constant_p(&(wq) == &system_freezable_power_efficient_wq) &&	\
+			 &(wq) == &system_freezable_power_efficient_wq, \
+			 "Please avoid flushing system_freezable_power_efficient_wq."); \
+	flush_workqueue(wq);						\
+})
+
 #endif
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index abcc9a2ac3197..5c612532f3e93 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2813,6 +2813,7 @@ static void warn_flush_attempt(struct workqueue_struct *wq)
  * This function sleeps until all work items which were queued on entry
  * have finished execution, but it is not livelocked by new incoming ones.
  */
+#undef flush_workqueue
 void flush_workqueue(struct workqueue_struct *wq)
 {
 	struct wq_flusher this_flusher = {
-- 

Tejun, can we use this approach? If yes, when to apply?

If we can include this patch into 5.18, can be applied as-is.
If we can include this patch into 5.19, can be applied with checks for
system_{long,unbound,highpri}_wq added because all flush_workqueue() users
on system_*_wq are gone in next-20220505.

Now that all flush_workqueue() users on system_*_wq are gone in next-20220505,
next step is to remove all flush_scheduled_work() users. Therefore, instead of
using /\bflush_workqueue\s*\(\s*system(_\w*)?_wq\s*\)/ in scripts/checkpatch.pl ,
I think we can ask BUILD_BUG_ON() for blocking new system_*_wq users, and ask
scripts/checkpatch.pl for blocking new system_wq users.

  reply	other threads:[~2022-05-05 13:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-24 23:31 [PATCH] checkpatch: warn about flushing system-wide workqueues Tetsuo Handa
2022-04-24 23:45 ` Joe Perches
2022-04-25  0:33   ` Tetsuo Handa
2022-05-05 13:42     ` Tetsuo Handa [this message]
2022-05-05 15:48       ` Joe Perches
2022-05-05 17:32       ` Tejun Heo
2022-05-05 23:29         ` Tetsuo Handa
2022-05-12 16:46           ` Tejun Heo
2022-05-16  1:32             ` [PATCH v2] workqueue: Wrap flush_workqueue() using a macro Tetsuo Handa
2022-05-16  5:00               ` [PATCH v3] " Tetsuo Handa
2022-05-16  7:18                 ` Joe Perches
2022-05-16  8:34                   ` Rasmus Villemoes
2022-05-20  8:01                 ` Tejun Heo
2022-05-20  9:51                   ` Tetsuo Handa
2022-05-20 11:11                     ` Tejun Heo
2022-05-20 11:43                       ` Tetsuo Handa
2022-05-20 17:10                         ` Tejun Heo
2022-05-21  1:14                           ` Tetsuo Handa
2022-05-21  4:57                             ` Tejun Heo
2022-05-21 11:37                               ` Tetsuo Handa
2022-05-23 19:04                                 ` Tejun Heo
2022-05-24 10:51                                   ` Tetsuo Handa
2022-05-27  6:21                                     ` [PATCH v4] workqueue: Wrap flush_workqueue() using an inline function Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=738afe71-2983-05d5-f0fc-d94efbdf7634@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=apw@canonical.com \
    --cc=dwaipayanray1@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.