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? Thanks. -- tejun
