- Subject: Re: [RFC, PATCH] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 8 Jun 2012 15:06:20 -0700
- Cc: Boaz Harrosh <bharrosh@xxxxxxxxxxx>, Tao Ma <boyu.mt@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>, v9fs-developer@xxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-afs@xxxxxxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx, linux-cifs@xxxxxxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx, codalist@xxxxxxxxxxxxxxxxxxxxxxxx, ecryptfs@xxxxxxxxxxxxxxx, osd-dev@xxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, fuse-devel@xxxxxxxxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx, jfs-discussion@xxxxxxxxxxxxxxxxxxxxx, logfs@xxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, linux-nilfs@xxxxxxxxxxxxxxx, linux-ntfs-dev@xxxxxxxxxxxxxxxxxxxxx, ocfs2-devel@xxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx
- In-reply-to: <20120608220049.GA18024@otc-wbsnb-06>
On Fri, Jun 8, 2012 at 3:00 PM, Kirill A. Shutemov
<kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
>
> IIUC, moving rcu_barrier() up should help, but I can't say that I fully
> understand SLAB_DESTROY_BY_RCU semantics.
.. hmm. I think you may be right. Even if we do move it up, we
probably shouldn't use it.
We don't even want SLAB_DESTROY_BY_RCU, since we do the delayed RCU
free for other reasons anyway, so it would duplicate the RCU delaying
and cause problems. I forgot about that little complication.
We could have a separate "RCU_BARRIER_ON_DESTROY" thing, but that's
just silly too.
Maybe your patch is the right thing.
Linus
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[LARTC]
[Bugtraq]
[Yosemite Forum]
[Photo]