lkml.org 
[lkml]   [2010]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 16/43] workqueue: kill cpu_populated_map
On 02/26, Tejun Heo wrote:
>
> @@ -1023,41 +991,40 @@ struct workqueue_struct *__create_workqueue_key(const char *name,
> ...
> + cpu_maps_update_done();
> ...
> +
> + spin_lock(&workqueue_lock);
> + list_add(&wq->list, &workqueues);
> + spin_unlock(&workqueue_lock);

OK, but if cpu_up() happens right after we drop cpu_maps_update_done(),
cwq->thread on the new CPU will run unbound?

> @@ -1127,47 +1091,30 @@ static int __devinit workqueue_cpu_callback(struct notifier_block *nfb,
> ...
> list_for_each_entry(wq, &workqueues, list) {

this becomes unsafe. create/destroy can modify workqueues list
in parallel.

> case CPU_ONLINE:
> - start_workqueue_thread(cwq, cpu);
> + __set_cpus_allowed(cwq->thread, get_cpu_mask(cpu),
> + true);

if the thread doesn't have PF_THREAD_BOUND, who will set it?

> case CPU_POST_DEAD:
> - cleanup_workqueue_thread(cwq);
> + lock_map_acquire(&cwq->wq->lockdep_map);
> + lock_map_release(&cwq->wq->lockdep_map);
> + flush_cpu_workqueue(cwq);

This can race with destroy_workqueue(), no?



I guess this patch is preparation, probably these problems should
go away later...

Oleg.



\
 
 \ /
  Last update: 2010-02-28 17:05    [W:0.428 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site