linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: jfs-discussion@lists.sourceforge.net,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com,
	linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org,
	linux-nilfs@vger.kernel.org, Boaz Harrosh <bharrosh@panasas.com>,
	v9fs-developer@lists.sourceforge.net, linux-ext4@vger.kernel.org,
	Nick Piggin <npiggin@kernel.dk>,
	fuse-devel@lists.sourceforge.net, Ma <boyu.mt@taobao.com>,
	ecryptfs@vger.kernel.org, reiserfs-devel@vger.kernel.org,
	osd-dev@open-osd.org, ceph-devel@vger.kernel.org,
	codalist@TELEMANN.coda.cs.cmu.edu, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net,
	samba-technical@lists.samba.org, linux-kernel@vger.kernel.org,
	logfs@logfs.org, Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Tao,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-btrfs@vger.kernel.org
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Fri, 8 Jun 2012 16:37:51 -0700	[thread overview]
Message-ID: <20120608163751.7a8ec2bc.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120608233127.GB18981@otc-wbsnb-06>

On Sat, 9 Jun 2012 02:31:27 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> 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 <viro@ZenIV.linux.org.uk> 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.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

  reply	other threads:[~2012-06-08 23:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 21:41 [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems Kirill A. Shutemov
2012-06-08 22:00 ` [RFC, PATCH] " Kirill A. Shutemov
2012-06-08 22:06   ` Linus Torvalds
2012-06-08 22:25     ` Al Viro
2012-06-08 22:02 ` [RFC, PATCH, RESEND] " Andrew Morton
2012-06-08 22:14   ` Kirill A. Shutemov
2012-06-08 22:23     ` Al Viro
2012-06-08 22:27       ` Linus Torvalds
2012-06-08 22:25     ` Andrew Morton
2012-06-08 22:27       ` Al Viro
2012-06-08 22:31         ` Andrew Morton
2012-06-08 22:36           ` Al Viro
2012-06-08 22:40             ` Andrew Morton
2012-06-08 23:32             ` Kirill A. Shutemov
2012-06-08 23:31           ` Kirill A. Shutemov
2012-06-08 23:37             ` Andrew Morton [this message]
2012-06-08 23:46               ` Linus Torvalds
2012-06-09  0:28                 ` Andrew Morton
2012-06-09  7:06                   ` Marco Stornelli
     [not found]                     ` <4FD2F5F4.1000106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-09  7:25                       ` Andrew Morton
2012-06-11  9:16                         ` Kirill A. Shutemov
2012-06-08 23:28       ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120608163751.7a8ec2bc.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bharrosh@panasas.com \
    --cc=boyu.mt@taobao.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=codalist@TELEMANN.coda.cs.cmu.edu \
    --cc=ecryptfs@vger.kernel.org \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=ldv@altlinux.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=logfs@logfs.org \
    --cc=npiggin@kernel.dk \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=osd-dev@open-osd.org \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).