Is not locking task_lock in cgroup_fork() safe?

Li Zefan lizefan at huawei.com
Wed Oct 17 07:26:26 UTC 2012


于 2012/10/17 3:34, Tejun Heo 写道:
> On Mon, Oct 08, 2012 at 03:57:52PM +0900, Tejun Heo wrote:
>> Hello, Li, Frederic.
>>
>> On Mon, Oct 08, 2012 at 01:46:18PM +0800, Li Zefan wrote:
>>> You're right. threadgroup lock is held unconditionally in attach_task_py_pid(),
>>> but it's held only for CLONE_THREAD in fork path, which I guess I overlooked
>>> when reviewing the patch.
>>>
>>>> Also, please note that task_lock is likely to be hot on local CPU at
>>>> that point and avoiding it there might not really buy much.
>>>
>>> Reverting that commit should be fine.
>>
>> There are other commits which perform similar optimization
>>
>>  7e3aa30ac8 ("cgroup: Remove task_lock() from cgroup_post_fork()")
>>  c84cdf75cc ("cgroup: Remove unnecessary task_lock before fetching css_set on migration")
>>
>> Are they wrong too?
> 
> Frederic, Li, Ping?
> 

Yes, they're wrong. I sugguest we revert those commits, and then fix cgroup_attach_task_all()
and others if still any.



More information about the Containers mailing list