From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from zeniv.linux.org.uk ([195.92.253.2]:55068 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbaDPEqW (ORCPT ); Wed, 16 Apr 2014 00:46:22 -0400 Date: Wed, 16 Apr 2014 05:46:18 +0100 From: Al Viro To: NeilBrown Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 17/19] VFS: set PF_FSTRANS while namespace_sem is held. Message-ID: <20140416044618.GX18016@ZenIV.linux.org.uk> References: <20140416033623.10604.69237.stgit@notabene.brown> <20140416040337.10604.86740.stgit@notabene.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20140416040337.10604.86740.stgit@notabene.brown> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote: > namespace_sem can be taken while various i_mutex locks are held, so we > need to avoid reclaim from blocking on an FS (particularly loop-back > NFS). I would really prefer to deal with that differently - by explicit change of gfp_t arguments of allocators. The thing is, namespace_sem is held *only* over allocations, and not a lot of them, at that - only mnt_alloc_id(), mnt_alloc_group_id(), alloc_vfsmnt() and new_mountpoint(). That is all that is allowed. Again, actual work with filesystems (setup, shutdown, remount, pathname resolution, etc.) is all done outside of namespace_sem; it's held only for manipulations of fs/{namespace,pnode}.c data structures and the only reason it isn't a spinlock is that we need to do some allocations. So I'd rather slap GFP_NOFS on those few allocations... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1853129DFD for ; Tue, 15 Apr 2014 23:46:25 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E959330404E for ; Tue, 15 Apr 2014 21:46:24 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id D8SGEm6zxQN8Az3P (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 15 Apr 2014 21:46:23 -0700 (PDT) Date: Wed, 16 Apr 2014 05:46:18 +0100 From: Al Viro Subject: Re: [PATCH 17/19] VFS: set PF_FSTRANS while namespace_sem is held. Message-ID: <20140416044618.GX18016@ZenIV.linux.org.uk> References: <20140416033623.10604.69237.stgit@notabene.brown> <20140416040337.10604.86740.stgit@notabene.brown> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140416040337.10604.86740.stgit@notabene.brown> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: NeilBrown Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote: > namespace_sem can be taken while various i_mutex locks are held, so we > need to avoid reclaim from blocking on an FS (particularly loop-back > NFS). I would really prefer to deal with that differently - by explicit change of gfp_t arguments of allocators. The thing is, namespace_sem is held *only* over allocations, and not a lot of them, at that - only mnt_alloc_id(), mnt_alloc_group_id(), alloc_vfsmnt() and new_mountpoint(). That is all that is allowed. Again, actual work with filesystems (setup, shutdown, remount, pathname resolution, etc.) is all done outside of namespace_sem; it's held only for manipulations of fs/{namespace,pnode}.c data structures and the only reason it isn't a spinlock is that we need to do some allocations. So I'd rather slap GFP_NOFS on those few allocations... _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs