On 09/07/2017 02:26 PM, Boqun Feng wrote: > On Thu, Sep 07, 2017 at 09:28:48AM +0200, Peter Zijlstra wrote: >> On Thu, Sep 07, 2017 at 11:34:12AM +0530, Prateek Sood wrote: >>> Remove circular dependency deadlock in a scenario where hotplug of CPU is >>> being done while there is updation in cgroup and cpuset triggered from >>> userspace. >>> >>> Example scenario: >>> kworker/0:0 => kthreadd => init:729 => init:1 => kworker/0:0 >>> >>> kworker/0:0 - percpu_down_write(&cpu_hotplug_lock) [held] >>> flush(work) [no high prio workqueue available on CPU] >>> wait_for_completion() > > Hi Prateek, > > so this is: > > _cpu_down(): > cpus_write_lock(); // percpu_down_write(&cpu_hotlug_lock) > cpuhp_invoke_callbacks(): > workqueue_offine_cpu(): > wq_update_unbound_numa(): > alloc_unbound_pool(): > get_unbound_pool(): > create_worker(): > kthread_create_on_node(): > wake_up_process(kthreadd_task); > wait_for_completion(); // create->done > > , right? > > Wonder running in a kworker is necessary to trigger this, I mean running > a cpu_down() in a normal process context could also trigger this, no? > Just ask out of curiosity. > > Regards, > Boqun Hi Boqun, cpu_down() in normal process can also trigger this. Regards Prateek > >>> >>> kthreadd - percpu_down_read(cgroup_threadgroup_rwsem) [waiting] >>> >>> init:729 - percpu_down_write(cgroup_threadgroup_rwsem) [held] >>> lock(cpuset_mutex) [waiting] >>> >>> init:1 - lock(cpuset_mutex) [held] >>> percpu_down_read(&cpu_hotplug_lock) [waiting] >> >> That's both unreadable and useless :/ You want to tell what code paths >> that were, not which random tasks happened to run them. >> >> > [...] > -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
