lkml.org 
[lkml]   [2009]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cgroup: Fixes the un-paired cgroup lock problem
Li Zefan wrote:
> Bill Davidsen wrote:
>
>> Li Zefan wrote:
>>
>>> Liu Aleaxander wrote:
>>>
>>>> From: Liu Aleaxander <Aleaxander@gmail.com>
>>>> Date: Wed, 4 Nov 2009 09:27:06 +0800
>>>> Subject: [PATCH] Fixes the un-paired cgroup lock problem
>>>>
>>>> In cgroup_lock_live_group, it locks the cgroup by mutex_lock, while
>>>> in the
>>>> cgroup_tasks_write, it unlock it by cgroup_unlock. Even though they are
>>>> equal, but I do think we should make it pair.
>>>>
>>>> BTW, should we replace others with cgroup_lock and cgroup_unlock?
>>>> Since we already have a wrapper one and it's meaningful.
>>>>
>>>>
>>> Before I read the email body, I thought there is a bug where
>>> there is a lock without unlock or vise versa.
>>>
>>> I agree the case here can be called "unpaired", but I'm not
>>> convinced this patch is needed. The code is not buggy or
>>> confusing. So the patch neither fixes a bug nor make the code
>>> more readable.
>>>
>>>
>> I would say it fixes a bug, the one that would be introduced when the
>> two methods are no longer compatible and essentially two names for the
>> same thing. And while you may know the code so well that you knew
>> without looking that this was (currently) okay, there will be lots of
>> eyes on this code over the years, I think most people would find use of
>> cgroup_lock to lock the cgroup a LOT more readable.
>>
>> While you can't go back in time to murder your grandfather, it creates
>> no paradox to fix a bug before someone writes it.
>>
>>
>
> cgroup_lock() is not necessarily more readable than mutex_lock(&cgroup_mutex),
> at least the former doesn't tell you the lock is a spin_lock or a mutex.
>
>
That's the point, cgroup_lock() is an abstraction, you want to lock the
cgroup, you call the macro, the macro handles the details, and if
thinking (or the most common cache configurations) change, the code
still works.

> In fact, Ingo showed his distaste towards cgroup_lock():
> http://lkml.org/lkml/2009/1/18/39
>
> And I won't worry about the issue you mentioned above. If It does
> happen, the one, who makes the 2 mehtods no long compatible, will
> definitely find out all the places where cgroup_mutex is used and
> make proper change.
>
>


--
Bill Davidsen <davidsen@tmr.com>
Unintended results are the well-earned reward for incompetence.



\
 
 \ /
  Last update: 2009-11-06 16:21    [W:0.416 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site