On Sun, Sep 9, 2012 at 2:11 AM, Tejun Heo <t...@kernel.org> wrote: > On Sun, Sep 09, 2012 at 02:07:50AM +0800, Lai Jiangshan wrote: >> when we release gcwq->lock and then grab it, we leave a hole that things >> can be changed. >> >> I don't want to open a hole. if the hole has bug we have to fix it. >> if the hole has no bug, we have to add lot of comments to explain it. >> >> When I write this reply. I am thinking: is the hole has bug if >> I release gcwq->lock here? result: no. But I don't want to add all things >> what I have thought as comments to explain there is no bug even when we >> open a hole. don't leave reviewers too much burden. > > We're already releasing gcwq->lock in maybe_create_worker(). That's > the reason why @ret is set to true. In addition, we already released > the lock to grab manager_mutex. So, you're not adding any burden. > Please reuse the busy rebinding mechanism. >
in 3.6 busy_worker_rebind() handle WORKER_REBIND bit, not WORKER_UNBOUND bit. busy_worker_rebind() takes struct work_struct *work argument, we have to add new patch to add a helper and restruct it at first. worker_maybe_bind_and_lock() 's mean is very clear here. busy_worker_rebind() seems for busy workers, manager is not busy workers. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
