[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100301155018.GA12031@redhat.com>
Date: Mon, 1 Mar 2010 16:50:18 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: torvalds@...ux-foundation.org, mingo@...e.hu, peterz@...radead.org,
awalls@...ix.net, linux-kernel@...r.kernel.org, jeff@...zik.org,
akpm@...ux-foundation.org, jens.axboe@...cle.com,
rusty@...tcorp.com.au, cl@...ux-foundation.org,
dhowells@...hat.com, arjan@...ux.intel.com, avi@...hat.com,
johannes@...solutions.net, andi@...stfloor.org
Subject: Re: [PATCH 16/43] workqueue: kill cpu_populated_map
On 03/02, Tejun Heo wrote:
>
> >> @@ -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.
>
> Yeap, has always been like that. Will be fixed by later changes.
>
> ...
>
> >> 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?
>
> Yes, it can and, again, has been always like that and will be fixed by
> later patches.
Hmm. not sure I understand... but before this patch the code was OK.
cpu_maps_update_begin() in create/destroy protected us from the races
with hotplug.
> I don't
> think it's worth fixing them at this point with all the pending
> changes.
OK, agreed.
Oleg.
--
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/
Powered by blists - more mailing lists