From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757027Ab0F3Sbs (ORCPT ); Wed, 30 Jun 2010 14:31:48 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:45930 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755575Ab0F3Sbr (ORCPT ); Wed, 30 Jun 2010 14:31:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <20100608004102.GQ31073@ZenIV.linux.org.uk> <87pqzrexon.fsf@linux.vnet.ibm.com> <871vbwe6lp.fsf@linux.vnet.ibm.com> <87mxuc91r2.fsf@linux.vnet.ibm.com> Date: Wed, 30 Jun 2010 11:31:38 -0700 Message-ID: Subject: Re: [V9fs-developer] [GIT PULL] 9p file system bug fixes for 2.6.35-rc2 From: Linus Torvalds To: Latchesar Ionkov Cc: "Aneesh Kumar K. V" , Eric Van Hensbergen , V9FS Developers , Al Viro , linux-kernel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 30, 2010 at 11:16 AM, Latchesar Ionkov wrote: > > I think that you need to use the s_vfs_rename_mutex in the super_block > struct instead of introducing a new rename_lock in the v9fs session. I actually think it's better to avoid having filesystems muck around with VFS locking details. Also, I think we get the VFS rename mutex only for cross-directory renames, and as mentioned, 9p needs locking even for regular directory renames. (Also, this way you can have parallel readers - although we could obviously change the vfs rename mutex into a rw-sem too). So I do think that keeping the logic private to a 9p-specific lock is the right solution here. Linus