From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [patch 05/27] fs: brlock vfsmount_lock
Date: Sat, 25 Apr 2009 04:50:40 +0100
Message-ID: <20090425035040.GW8633@ZenIV.linux.org.uk>
References: <20090425012020.457460929@suse.de> <20090425012209.656162021@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
To: npiggin@suse.de
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:35146 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751773AbZDYDul (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 24 Apr 2009 23:50:41 -0400
Content-Disposition: inline
In-Reply-To: <20090425012209.656162021@suse.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sat, Apr 25, 2009 at 11:20:25AM +1000, npiggin@suse.de wrote:

[overall: sane idea, but...]

> +void vfsmount_read_lock(void)
> +{
> +	spinlock_t *lock;
> +
> +	lock = &get_cpu_var(vfsmount_lock);
> +	spin_lock(lock);
> +}
> +
> +void vfsmount_read_unlock(void)
> +{
> +	spinlock_t *lock;
> +
> +	lock = &__get_cpu_var(vfsmount_lock);
> +	spin_unlock(lock);
> +	put_cpu_var(vfsmount_lock);
> +}

These might be hot enough to be worth inlining, at least in fs/namei.c
users.  Or not - really needs testing.

> @@ -68,9 +113,9 @@ static int mnt_alloc_id(struct vfsmount
>  
>  retry:
>  	ida_pre_get(&mnt_id_ida, GFP_KERNEL);
> -	spin_lock(&vfsmount_lock);
> +	vfsmount_write_lock();
>  	res = ida_get_new(&mnt_id_ida, &mnt->mnt_id);
> -	spin_unlock(&vfsmount_lock);
> +	vfsmount_write_unlock();

Yuck.  _Really_ an overkill here.

>  static void mnt_free_id(struct vfsmount *mnt)
>  {
> -	spin_lock(&vfsmount_lock);
> +	vfsmount_write_lock();
>  	ida_remove(&mnt_id_ida, mnt->mnt_id);
> -	spin_unlock(&vfsmount_lock);
> +	vfsmount_write_unlock();
>  }

Ditto.

Missing: description of when we need it for read/when we need it for write.