Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762062Ab2FHXiY (ORCPT ); Fri, 8 Jun 2012 19:38:24 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:35506 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761835Ab2FHXhx (ORCPT ); Fri, 8 Jun 2012 19:37:53 -0400 Date: Fri, 8 Jun 2012 16:37:51 -0700 From: Andrew Morton To: "Kirill A. Shutemov" Cc: Al Viro , Linus Torvalds , Boaz Harrosh , Tao Ma , Nick Piggin , "Dmitry V. Levin" , v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, codalist@TELEMANN.coda.cs.cmu.edu, ecryptfs@vger.kernel.org, osd-dev@open-osd.org, linux-ext4@vger.kernel.org, fuse-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, logfs@logfs.org, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems Message-Id: <20120608163751.7a8ec2bc.akpm@linux-foundation.org> In-Reply-To: <20120608233127.GB18981@otc-wbsnb-06> References: <1339191663-17693-1-git-send-email-kirill.shutemov@linux.intel.com> <20120608150253.e42464a6.akpm@linux-foundation.org> <20120608221446.GA18250@otc-wbsnb-06> <20120608152550.258d6a30.akpm@linux-foundation.org> <20120608222734.GT30000@ZenIV.linux.org.uk> <20120608153120.b722d7c3.akpm@linux-foundation.org> <20120608233127.GB18981@otc-wbsnb-06> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2061 Lines: 52 On Sat, 9 Jun 2012 02:31:27 +0300 "Kirill A. Shutemov" wrote: > On Fri, Jun 08, 2012 at 03:31:20PM -0700, Andrew Morton wrote: > > On Fri, 8 Jun 2012 23:27:34 +0100 > > Al Viro wrote: > > > > > On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote: > > > > > > > A neater implementation might be to add a kmem_cache* argument to > > > > unregister_filesystem(). If that is non-NULL, unregister_filesystem() > > > > does the rcu_barrier() and destroys the cache. That way we get to > > > > delete (rather than add) a bunch of code from all filesystems and new > > > > and out-of-tree filesystems cannot forget to perform the rcu_barrier(). > > > > > > There's often enough more than one cache, so that one is no-go. > > > > kmem_cache** ;) > > > > Which filesystems have multiple inode caches? > > Multiple inode caches? No. > Multiple caches with call_rcu() free? See btrfs or gfs2. OK. But for those non-inode caches, the rcu treatment is private to the filesystem. Hence it is appropriate that the filesystem call rcu_barrier() for those caches. But in the case of the inode caches, the rcu treatment is a vfs thing, so it is the vfs which should perform the rcu_barrier(). This is a red herring - those non-inode caches have nothing to do with the issue we're dicussing. So how about open-coding the rcu_barrier() in btrfs and gfs2 for the non-inode caches (which is the appropriate place), and hand the inode cache over to the vfs for treatment (which is the appropriate place). The downside is that btrfs and gfs2 will do an extra rcu_barrier() at umount time. Shrug. If they really want to super-optimise that, they can skip the private rcu_barrier() call and assume that the vfs will be doing it. Not a good idea, IMO. -- 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/