From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Subject: Re: [PATCH] VFS: br_write_lock locks on possible CPUs other than
 online CPUs
Date: Tue, 20 Dec 2011 13:07:44 +0530
Message-ID: <4EF03B48.6000006@linux.vnet.ibm.com>
References: <1324265775.25089.20.camel@mengcong> <4EEEE866.2000203@linux.vnet.ibm.com> <4EEF0003.3010800@codeaurora.org> <4EEF1A13.4000801@linux.vnet.ibm.com> <20111219121100.GI2203@ZenIV.linux.org.uk> <4EEF9D4E.1000008@linux.vnet.ibm.com> <20111219205251.GK2203@ZenIV.linux.org.uk> <4EF01565.2000700@linux.vnet.ibm.com> <20111220062710.GC23916@ZenIV.linux.org.uk> <1324366218.21588.5.camel@mengcong>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Nick Piggin <npiggin@kernel.dk>, david@fromorbit.com,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Maciej Rutecki <maciej.rutecki@gmail.com>
To: mc@linux.vnet.ibm.com
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from e23smtp08.au.ibm.com ([202.81.31.141]:56004 "EHLO
	e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752601Ab1LTHhz (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 20 Dec 2011 02:37:55 -0500
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <linux-fsdevel@vger.kernel.org> from <srivatsa.bhat@linux.vnet.ibm.com>;
	Tue, 20 Dec 2011 07:36:09 +1000
In-Reply-To: <1324366218.21588.5.camel@mengcong>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 12/20/2011 01:00 PM, mengcong wrote:

> On Tue, 2011-12-20 at 06:27 +0000, Al Viro wrote:
>> On Tue, Dec 20, 2011 at 10:26:05AM +0530, Srivatsa S. Bhat wrote:
>>> Oh, right, that has to be handled as well...
>>>
>>> Hmmm... How about registering a CPU hotplug notifier callback during lock init
>>> time, and then for every cpu that gets onlined (after we took a copy of the
>>> cpu_online_mask to work with), we see if that cpu is different from the ones
>>> we have already locked, and if it is, we lock it in the callback handler and
>>> update the locked_cpu_mask appropriately (so that we release the locks properly
>>> during the unlock operation).
>>>
>>> Handling the newly introduced race between the callback handler and lock-unlock
>>> code must not be difficult, I believe..
>>>
>>> Any loopholes in this approach? Or is the additional complexity just not worth
>>> it here?
>>
>> To summarize the modified variant of that approach hashed out on IRC:
>>
> On which IRC do you discuss?


#kernel on tinc.sekrit.org :-)

Regards,
Srivatsa S. Bhat