Re: [PATCH v3] workqueue: Wrap flush_workqueue() using a macro

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

On 2022/05/21 2:10, Tejun Heo wrote:
> On Fri, May 20, 2022 at 08:43:41PM +0900, Tetsuo Handa wrote:
>> All flush_workqueue(system_*_wq) users are gone in linux-next.git, and this patch
>> is for preventing new flush_workqueue(system_*_wq) users from coming in.
> 
> Are we fully sure? Also, there can be other changes in flight which aren't
> covered. It's just not nice in general to intentionally trigger build
> failures without an easy way to remediate it.

Yes, we are fully sure. Subset of this patch is already in linux-next.git without problems.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20220520&id=5015b3b61696f8f44e7113e5bc14f4a20cbf57ff
There aren't other changes in flight which aren't covered.

I believe that it is safe to replace the commit above with this patch when Linus released
5.18 final (or maybe 5.18-rc8) is released next Sunday. I also believe that it is safe to
send this patch right before Linus releases 5.19-rc1.

I guess that there are several out-of-tree kernel modules which will start
failing with this patch. But they can use

	#undef flush_workqueue

as a temporary workaround (if they can't remediate easily) until we add WARN_ON()
as a run-time check. We will need to wait for several months until we can add
WARN_ON() as a run-time check, for that happens after all flush_scheduled_work()
users are gone.

>> Therefore, triggering a build error (by sending this patch to linux.git right
>> before 5.19-rc1 in order to make sure that developers will not use
>> flush_workqueue(system_*_wq) again) is what this patch is for.
> 
> What I'm trying to say is that, if we can trigger build warnings, that'd be
> a better way to go about it.

Some unlucky users (if any) can workaround this build failure using #undef.
Nothing to bother with how to emit warning messages instead of error messages.