Message-ID: <4AF28695.7070806@cn.fujitsu.com>
Date: Thu, 05 Nov 2009 16:02:29 +0800
From: Li Zefan <lizf@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: Bill Davidsen <davidsen@tmr.com>
CC: Liu Aleaxander <aleaxander@gmail.com>, Paul Menage <menage@google.com>,
       linux-kernel@vger.kernel.org, containers@lists.osdl.org
Subject: Re: [PATCH] cgroup: Fixes the un-paired cgroup lock problem
References: <b741c2440911031740m52f8c11dt6e57b549cc6ce465@mail.gmail.com> <4AF10CEE.5020807@cn.fujitsu.com> <4AF18F06.50807@tmr.com>
In-Reply-To: <4AF18F06.50807@tmr.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2149
Lines: 51

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.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/