All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Tejun Heo <tj@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	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, 05 May 2022 08:48:31 -0700	[thread overview]
Message-ID: <ed8f50726d0a8b8e5dc9da14ce64039891b77b53.camel@perches.com> (raw)
In-Reply-To: <738afe71-2983-05d5-f0fc-d94efbdf7634@I-love.SAKURA.ne.jp>

On Thu, 2022-05-05 at 22:42 +0900, Tetsuo Handa wrote:
> 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.
[]
> diff --git 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)

The #undef flush_workqueue could be removed by using

void (flush_workqueue)(struct workqueue_struct *wq)
{
	...
}



  reply	other threads:[~2022-05-05 15:58 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
2022-05-05 15:48       ` Joe Perches [this message]
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=ed8f50726d0a8b8e5dc9da14ce64039891b77b53.camel@perches.com \
    --to=joe@perches.com \
    --cc=apw@canonical.com \
    --cc=dwaipayanray1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --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.