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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <538ED7EB.5050303@cn.fujitsu.com>
Date:	Wed, 4 Jun 2014 16:25:15 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	<jjherne@...ux.vnet.ibm.com>, Sasha Levin <sasha.levin@...cle.com>,
	Tejun Heo <tj@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: workqueue: WARN at at kernel/workqueue.c:2176

On 06/04/2014 02:49 PM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 10:27:25AM +0800, Lai Jiangshan wrote:
>>> Hmm, yes I think you're right. A queued wakeup can miss an affinity
>>> change like that.
>>>
>>> Something like the below ought to cure that I suppose..
>>
>> As a non-scheduler developer, I can't find anything wrong with the patch
>> (I searched all on_rq in kernel/sched).
> 
> You did fine finding that hole, so who knows, you might become one real
> soon now ;-)
> 
>> but I think __migrate_task() is slow path comparing to sched_ttwu_pending().
>> So I prefer to change set_cpus_allowed_ptr() and __migrate_task() rather than
>> to sched_ttwu_pending().
> 
> Yes, I agree, something there would be better, but I couldn't find
> anything without holes in.
> 
> 

I think the following code works. (inspirited from the sched_ttwu_pending() in migration_call().)

if p->on_rq == 0 && p->state == TASK_WAKING in __migrate_task() after this patch,
it means the cpuallowed is changed before __migrate_task() along with other scheduler
movements happens between sched_ttwu_pending() and __migrate_task().


diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..277f3bc 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);
@@ -4656,6 +4656,7 @@ static int migration_cpu_stop(void *data)
 	 * be on another cpu but it doesn't matter.
 	 */
 	local_irq_disable();
+	sched_ttwu_pending();
 	__migrate_task(arg->task, raw_smp_processor_id(), arg->dest_cpu);
 	local_irq_enable();
 	return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/