On Thu, Apr 03, 2014 at 11:01:28AM -0400, Tejun Heo wrote: > Hello, > > On Thu, Apr 03, 2014 at 04:48:28PM +0200, Frederic Weisbecker wrote: > > > Wouldn't the right thing to do would be factoring out > > > apply_workqueue_attrs_locked()? It's cleaner to block out addition of > > > new workqueues while the masks are being updated anyway. > > > > I'm not quite sure I get what you suggest. Do you mean have > > apply_workqueue_attrs_locked() calling apply_workqueue_attrs() under > > the lock on this patch? > > Not sure it still matters but I was suggesting that creating > apply_workqueue_attrs_locked() which requires the caller to handle > locking and making apply_workqueue_attrs() a wrapper which grabs and > releases lock around it, and using the former in locked iteration > would work. lol has this explanation made it any clearer or is it > even worse now? :)
I see, it gets a little better now :) Maybe it still matters because I still need to iterate over unbound workqueues to apply an update on "cpu_unbound_wqs_mask". And the list must remain stable while I call apply_workqueue_attrs() on workqueues. Anyway, we'll see how it looks like :) -- 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/
