Re: workqueue: WARN at at kernel/workqueue.c:2176

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Tue, Jun 03, 2014 at 08:45:39PM +0800, Lai Jiangshan wrote:
> 
> Hi, Peter,
> 
> I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
> so the part for workqueue of the old analyse maybe be wrong.)

But I don't think there is any guarantee we'll do the wakeup before
running the stop work.

Suppose the initial task gets queued, and the thing gets send the
interrupt, meanwhile we'll do the stopper work wakeup !queueing, the
set_cpus_allowed_ptr() isn't crossing llc boundaries.

Now, the remote cpu preempts/schedules before the interrupt hits and
runs the stop task.

At which point we'll run __migrate_task() while the task is still queued
on the wake list.

> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 268a45e..1a198a5 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4530,7 +4530,7 @@ int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask *new_mask)
>  		goto out;
>  
>  	dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
> -	if (p->on_rq) {
> +	if (p->on_rq || p->state == TASK_WAKING) {
>  		struct migration_arg arg = { p, dest_cpu };
>  		/* Need help from migration thread: drop lock and wait. */
>  		task_rq_unlock(rq, p, &flags);

So while this will close the window somewhat, I don't think its entirely
closed.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]