Re: [PATCH] workqueue: Fix pool->nr_running type back to atomic

[yunlong xing]

On Wed, Feb 7, 2024 at 12:52 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> Hello,
>
> On Tue, Feb 06, 2024 at 04:00:24PM +0800, Yunlong Xing wrote:
> > In CPU-hotplug test, when plug the core, set_cpus_allowed_ptr() restoring
> > the cpus_mask of the per-cpu worker may fail, the cpus_mask of the worker
> > remain wq_unbound_cpumask until the core hotpluged next time. so, workers
> > in the same per-cpu pool can run concurrently and change nr_running at the
> >  same time, atomic problem occur.
>
> How would set_cpus_allowed_ptr() fail? That should trigger WARN_ON, right?
> If set_cpus_allowed_ptr() fails, nr_running getting desynchronized is only a
> part of the problem. We will end up running per-cpu work items which must
> execute on the same CPU on foreign CPUs.

Hi tejun，

Yes, WARN_ON is triggered. The reason of  set_cpus_allowed_ptr() fail  still
needs to be further investigated.

I was originally planning to inquire workqueue whether or not allows the worker
that associated with one cpu running on the other cpus？From your reply，the
answer of my question is not allow，right？

>
> Thanks.
>
> --
> tejun