Messages in this thread Patch in this message | | | Date | Wed, 13 Jan 2021 09:52:49 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 3/4] workqueue: Tag bound workers with KTHREAD_IS_PER_CPU |
| |
On Wed, Jan 13, 2021 at 02:16:10PM +0000, Valentin Schneider wrote: > On 13/01/21 21:28, Lai Jiangshan wrote: > > On Tue, Jan 12, 2021 at 10:51 PM Peter Zijlstra <peterz@infradead.org> wrote: > >> @@ -4972,9 +4977,11 @@ static void rebind_workers(struct worker > >> * of all workers first and then clear UNBOUND. As we're called > >> * from CPU_ONLINE, the following shouldn't fail. > >> */ > >> - for_each_pool_worker(worker, pool) > >> + for_each_pool_worker(worker, pool) { > >> WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, > >> pool->attrs->cpumask) < 0); > >> + kthread_set_per_cpu(worker->task, true); > > > > Will the schedule break affinity in the middle of these two lines due to > > patch4 allowing it and result in Paul's reported splat. > > > > You might be right; at this point we would still have BALANCE_PUSH set, > so something like the below could happen > > rebind_workers() > set_cpus_allowed_ptr() > affine_move_task() > task_running() => stop_one_cpu() > > ... // Stopper migrates the kworker here in the meantime > > switch_to(<pcpu kworker>) // Both cpuhp thread and kworker should be enqueued > // here, so one or the other could be picked > balance_switch() > balance_push() > ^-- no KTHREAD_IS_PER_CPU ! > > This should however trigger the WARN_ON_ONCE() in kthread_set_per_cpu() > *before* the one in process_one_work(), which I haven't seen in Paul's > mails.
The 56 instances of one-hour SRCU-P scenarios hit the WARN_ON_ONCE() in process_one_work() once, but there is no sign of a WARN_ON_ONCE() from kthread_set_per_cpu(). But to your point, this does appear to be a rather low-probability race condition, once per some tens of hours of SRCU-P.
Is there a more focused check for the race condition above?
Thanx, Paul
| |