On Tue, 23 May 2023 at 02:42, Tejun Heo <tj@xxxxxxxxxx> wrote: > > On Mon, May 22, 2023 at 08:20:38AM -1000, Tejun Heo wrote: > > Hello, > > > > On Mon, May 22, 2023 at 09:24:09PM +0800, Z qiang wrote: > > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > > > index 9c5c1cfa478f..f8d739fef311 100644 > > > --- a/kernel/workqueue.c > > > +++ b/kernel/workqueue.c > > > @@ -1060,10 +1060,9 @@ void wq_worker_running(struct task_struct *task) > > > * and leave with an unexpected pool->nr_running == 1 on the newly > > > unbound > > > * pool. Protect against such race. > > > */ > > > - preempt_disable(); > > > + local_irq_disable(); > > > if (!(worker->flags & WORKER_NOT_RUNNING)) > > > worker->pool->nr_running++; > > > - preempt_enable(); > > > > > > /* > > > * CPU intensive auto-detection cares about how long a work item > > > hogged > > > @@ -1072,6 +1071,7 @@ void wq_worker_running(struct task_struct *task) > > > worker->current_at = worker->task->se.sum_exec_runtime; > > > > > > worker->sleeping = 0; > > > + local_irq_enable(); > > > } > > > > Ah, yeah, this is correct. Now we're modifying nr_running from timer tick > > too, so if don't block irq, the timer tick can ruin the not-irq-protected > > read-write-modify nr_running update from wq_worker_running(). Naresh, can > > you please confirm the fix? > > Z qiang, while waiting for Naresh's test result, can you send the fix as a > proper signed-off-patch? The proposed patch applied on top of Linux next and boot tested for more than 100 times and is still running in a loop by Anders. The reported warning did not reproduce again. Tested-by: Anders Roxell <anders.roxell@xxxxxxxxxx> Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx> - Naresh > > Thanks. > > -- > tejun
