On 04/27, Andrew Morton wrote:
>
> We have a huge amount of change pending in the kthread/workqueue/freezer
> area, partly because I decided not to merge most of the workqueue changes
> into 2.6.21.
>
> It'd be good if people could take some time to sit down and re-review the
> code which we presently have. I plan on sending it all off for 2.6.22 and
> there might be some glitches but it seems to have a good track record so
> far.
Oops. I completely misread the ->cpus_allowed check in try_to_wake_up(), and
so workqueue_cpu_callback() needs a simple fix: CPU_UP_CANCELED should rebind
cwq->thread. Or, better, we should not bind the task until CPU_ONLINE.
I'll send the patch soon, but it conflicts with Rafael's
add-suspend-related-notifications-for-cpu-hotplug.patch
, so I am sending this cleanup first to make them independent.
Actually, I believe almost all subsystems could be simplified as well, most
of them don't care about CPU_TASKS_FROZEN bit.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- OLD/kernel/workqueue.c~1_FROZEN 2007-05-01 22:13:10.000000000 +0400
+++ OLD/kernel/workqueue.c 2007-05-01 22:18:15.000000000 +0400
@@ -747,6 +747,8 @@ static int __devinit workqueue_cpu_callb
struct cpu_workqueue_struct *cwq;
struct workqueue_struct *wq;
+ action &= ~CPU_TASKS_FROZEN;
+
switch (action) {
case CPU_LOCK_ACQUIRE:
mutex_lock(&workqueue_mutex);
@@ -757,7 +759,6 @@ static int __devinit workqueue_cpu_callb
return NOTIFY_OK;
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
cpu_set(cpu, cpu_populated_map);
}
@@ -766,23 +767,19 @@ static int __devinit workqueue_cpu_callb
switch (action) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
if (!create_workqueue_thread(cwq, cpu))
break;
printk(KERN_ERR "workqueue for %i failed\n", cpu);
return NOTIFY_BAD;
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
wake_up_process(cwq->thread);
break;
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
if (cwq->thread)
wake_up_process(cwq->thread);
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
cleanup_workqueue_thread(cwq, cpu);
break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
