Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Mon, 10 Jul 2023 10:40:42 -1000
From:   Tejun Heo <tj@kernel.org>
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     Lai Jiangshan <jiangshanlai@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH for 6.5] workqueue: Warn attempt to flush system-wide
 workqueues.
Message-ID: <ZKxsyh0QlqQfQRD0@slm.duckdns.org>
References: <42f1067f-3232-0a64-4c19-6165dabf46d0@I-love.SAKURA.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42f1067f-3232-0a64-4c19-6165dabf46d0@I-love.SAKURA.ne.jp>
Precedence: bulk

On Fri, Jun 30, 2023 at 09:28:53PM +0900, Tetsuo Handa wrote:
> Based on commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
> a macro"), all in-tree users stopped flushing system-wide workqueues.
> Therefore, start emitting runtime message so that all out-of-tree users
> will understand that they need to update their code.
> 
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Applied to wq/for-6.6.

> After this patch, flush_workqueue(wq) where wq cannot be determined at build
> time will not get runtime warning. Should we now start checking wq at run time
> so that we get runtime warning when wq is system-wide?

Yeah, we can add an internal flag for these standard workqueues and trigger
warning when somebody tries to flush them.

Thanks.

-- 
tejun