All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
	Nick Piggin <npiggin@kernel.dk>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	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,
	rei
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Sat, 09 Jun 2012 09:06:28 +0200	[thread overview]
Message-ID: <4FD2F5F4.1000106@gmail.com> (raw)
In-Reply-To: <20120608172842.9826b5cd.akpm@linux-foundation.org>

Il 09/06/2012 02:28, Andrew Morton ha scritto:
> On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds<torvalds@linux-foundation.org>  wrote:
>
>> Of course, if you just mean having a VFS wrapper that does
>>
>>      static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
>>      {
>>          rcu_barrier();
>>          kmem_cache_destroy(cachep);
>>      }
>>
>> then we could do that. Not much better than what Kirill's patch did,
>> but at least we could have that comment in just one single place.
>
> That's conceptually what I meant.  But it has the problem that new and
> out-of-tree filesystems might forget to do it.  Which is why I suggest
> adding a kmem_cache* argument to unregister_filesystem() for this.
>
> It's a bit awkward, and the fs can pass in NULL if it knows what it's
> doing.  But it's reliable.
> --

The call of rcu_barrier should be mandatory for the "unload fs module" 
problem, right? If the fs is compiled statically maybe we could avoid 
it, but (eventually) this kind of decision is per-fs, so this could be a 
clue that the call of rcu_barrier maybe is inside each fs not in VFS.

Marco

WARNING: multiple messages have this Message-ID (diff)
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
	Nick Piggin <npiggin@kernel.dk>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	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
Date: Sat, 09 Jun 2012 09:06:28 +0200	[thread overview]
Message-ID: <4FD2F5F4.1000106@gmail.com> (raw)
In-Reply-To: <20120608172842.9826b5cd.akpm@linux-foundation.org>

Il 09/06/2012 02:28, Andrew Morton ha scritto:
> On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds<torvalds@linux-foundation.org>  wrote:
>
>> Of course, if you just mean having a VFS wrapper that does
>>
>>      static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
>>      {
>>          rcu_barrier();
>>          kmem_cache_destroy(cachep);
>>      }
>>
>> then we could do that. Not much better than what Kirill's patch did,
>> but at least we could have that comment in just one single place.
>
> That's conceptually what I meant.  But it has the problem that new and
> out-of-tree filesystems might forget to do it.  Which is why I suggest
> adding a kmem_cache* argument to unregister_filesystem() for this.
>
> It's a bit awkward, and the fs can pass in NULL if it knows what it's
> doing.  But it's reliable.
> --

The call of rcu_barrier should be mandatory for the "unload fs module" 
problem, right? If the fs is compiled statically maybe we could avoid 
it, but (eventually) this kind of decision is per-fs, so this could be a 
clue that the call of rcu_barrier maybe is inside each fs not in VFS.

Marco

WARNING: multiple messages have this Message-ID (diff)
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
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, codalist@telemann.coda.cs.cmu.edu,
	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, Tao Ma <boyu.mt@taobao.com>,
	ecryptfs@vger.kernel.org, reiserfs-devel@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net,
	samba-technical@lists.samba.org, linux-kernel@vger.kernel.org,
	logfs@logfs.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-btrfs@vger.kernel.org, osd-dev@open-osd.org
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Sat, 09 Jun 2012 09:06:28 +0200	[thread overview]
Message-ID: <4FD2F5F4.1000106@gmail.com> (raw)
In-Reply-To: <20120608172842.9826b5cd.akpm@linux-foundation.org>

Il 09/06/2012 02:28, Andrew Morton ha scritto:
> On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds<torvalds@linux-foundation.org>  wrote:
>
>> Of course, if you just mean having a VFS wrapper that does
>>
>>      static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
>>      {
>>          rcu_barrier();
>>          kmem_cache_destroy(cachep);
>>      }
>>
>> then we could do that. Not much better than what Kirill's patch did,
>> but at least we could have that comment in just one single place.
>
> That's conceptually what I meant.  But it has the problem that new and
> out-of-tree filesystems might forget to do it.  Which is why I suggest
> adding a kmem_cache* argument to unregister_filesystem() for this.
>
> It's a bit awkward, and the fs can pass in NULL if it knows what it's
> doing.  But it's reliable.
> --

The call of rcu_barrier should be mandatory for the "unload fs module" 
problem, right? If the fs is compiled statically maybe we could avoid 
it, but (eventually) this kind of decision is per-fs, so this could be a 
clue that the call of rcu_barrier maybe is inside each fs not in VFS.

Marco

WARNING: multiple messages have this Message-ID (diff)
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
	Nick Piggin <npiggin@kernel.dk>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	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,
	rei
Subject: [Ocfs2-devel] [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Sat, 09 Jun 2012 09:06:28 +0200	[thread overview]
Message-ID: <4FD2F5F4.1000106@gmail.com> (raw)
In-Reply-To: <20120608172842.9826b5cd.akpm@linux-foundation.org>

Il 09/06/2012 02:28, Andrew Morton ha scritto:
> On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds<torvalds@linux-foundation.org>  wrote:
>
>> Of course, if you just mean having a VFS wrapper that does
>>
>>      static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
>>      {
>>          rcu_barrier();
>>          kmem_cache_destroy(cachep);
>>      }
>>
>> then we could do that. Not much better than what Kirill's patch did,
>> but at least we could have that comment in just one single place.
>
> That's conceptually what I meant.  But it has the problem that new and
> out-of-tree filesystems might forget to do it.  Which is why I suggest
> adding a kmem_cache* argument to unregister_filesystem() for this.
>
> It's a bit awkward, and the fs can pass in NULL if it knows what it's
> doing.  But it's reliable.
> --

The call of rcu_barrier should be mandatory for the "unload fs module" 
problem, right? If the fs is compiled statically maybe we could avoid 
it, but (eventually) this kind of decision is per-fs, so this could be a 
clue that the call of rcu_barrier maybe is inside each fs not in VFS.

Marco

  reply	other threads:[~2012-06-09  7:13 UTC|newest]

Thread overview: 62+ 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 21:41 ` Kirill A. Shutemov
2012-06-08 21:41 ` Kirill A. Shutemov
2012-06-08 22:00 ` [RFC, PATCH] " Kirill A. Shutemov
2012-06-08 22:00   ` Kirill A. Shutemov
2012-06-08 22:00   ` Kirill A. Shutemov
2012-06-08 22:06   ` Linus Torvalds
2012-06-08 22:06     ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 22:06     ` Linus Torvalds
2012-06-08 22:06     ` Linus Torvalds
2012-06-08 22:25     ` Al Viro
2012-06-08 22:25       ` [Ocfs2-devel] " Al Viro
2012-06-08 22:25       ` Al Viro
2012-06-08 22:25       ` Al Viro
2012-06-08 22:02 ` [RFC, PATCH, RESEND] " Andrew Morton
2012-06-08 22:02   ` [Ocfs2-devel] " Andrew Morton
2012-06-08 22:02   ` Andrew Morton
2012-06-08 22:14   ` Kirill A. Shutemov
2012-06-08 22:14     ` Kirill A. Shutemov
2012-06-08 22:23     ` Al Viro
2012-06-08 22:23       ` [Ocfs2-devel] " Al Viro
2012-06-08 22:23       ` Al Viro
2012-06-08 22:27       ` Linus Torvalds
2012-06-08 22:27         ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 22:27         ` Linus Torvalds
2012-06-08 22:25     ` Andrew Morton
2012-06-08 22:25       ` [Ocfs2-devel] " Andrew Morton
2012-06-08 22:25       ` Andrew Morton
2012-06-08 22:27       ` Al Viro
2012-06-08 22:27         ` [Ocfs2-devel] " Al Viro
2012-06-08 22:27         ` Al Viro
2012-06-08 22:31         ` Andrew Morton
2012-06-08 22:31           ` [Ocfs2-devel] " Andrew Morton
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:31             ` Kirill A. Shutemov
2012-06-08 23:37             ` Andrew Morton
2012-06-08 23:37               ` [Ocfs2-devel] " Andrew Morton
2012-06-08 23:37               ` Andrew Morton
2012-06-08 23:37               ` Andrew Morton
2012-06-08 23:46               ` Linus Torvalds
2012-06-08 23:46                 ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 23:46                 ` Linus Torvalds
2012-06-09  0:28                 ` Andrew Morton
2012-06-09  0:28                   ` [Ocfs2-devel] " Andrew Morton
2012-06-09  0:28                   ` Andrew Morton
2012-06-09  7:06                   ` Marco Stornelli [this message]
2012-06-09  7:06                     ` [Ocfs2-devel] " Marco Stornelli
2012-06-09  7:06                     ` Marco Stornelli
2012-06-09  7:06                     ` Marco Stornelli
     [not found]                     ` <4FD2F5F4.1000106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-09  7:25                       ` Andrew Morton
2012-06-09  7:25                         ` [Ocfs2-devel] " Andrew Morton
2012-06-09  7:25                         ` Andrew Morton
2012-06-09  7:25                         ` Andrew Morton
2012-06-11  9:16                         ` Kirill A. Shutemov
2012-06-11  9:16                           ` Kirill A. Shutemov
2012-06-11  9:16                           ` Kirill A. Shutemov
2012-06-08 23:28       ` 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=4FD2F5F4.1000106@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.