OpenVZ Forum


Home » Mailing lists » Devel » [PATCH 0/3] Fix problem with static_key decrement
Re: [PATCH 2/3] don't take cgroup_mutex in destroy() [message #45976 is a reply to message #45949] Fri, 20 April 2012 00:30 Go to previous messageGo to previous message
Li Zefan is currently offline  Li Zefan
Messages: 90
Registered: February 2008
Member
Tejun Heo wrote:

> On Thu, Apr 19, 2012 at 07:49:17PM -0300, Glauber Costa wrote:
>> Most of the destroy functions are only doing very simple things
>> like freeing memory.
>>
>> The ones who goes through lists and such, already use its own
>> locking for those.
>>
>> * The cgroup itself won't go away until we free it, (after destroy)
>> * The parent won't go away because we hold a reference count
>> * There are no more tasks in the cgroup, and the cgroup is declared
>> dead (cgroup_is_removed() == true)
>>
>> For the blk-cgroup and the cpusets, I got the impression that the mutex
>> is still necessary.
>>
>> For those, I grabbed it from within the destroy function itself.
>>
>> If the maintainer for those subsystems consider it safe to remove
>> it, we can discuss it separately.
>
> I really don't like cgroup_lock() usage spreading more. It's
> something which should be contained in cgroup.c proper. I looked at
> the existing users a while ago and they seemed to be compensating
> deficencies in API, so, if at all possible, let's not spread the
> disease.
>


Agreed. I used to do cleanups to remove cgroup_lock()s in subsystems
which are really not necessary.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [PATCH 3/3] SUNRPC: set per-net PipeFS superblock before notification
Next Topic: [PATCH v2 0/5] Fix problem with static_key decrement
Goto Forum:
  


Current Time: Fri Sep 12 12:07:00 GMT 2025

Total time taken to generate the page: 0.07251 seconds