linux-ext4 - Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFw5k3daxeoZb9H1HGcOCWjPF+d7inSbf0QHmG-atp4reQ@mail.gmail.com>
Date:	Fri, 8 Jun 2012 16:46:47 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Boaz Harrosh <bharrosh@...asas.com>,
	Tao Ma <boyu.mt@...bao.com>, Nick Piggin <npiggin@...nel.dk>,
	"Dmitry V. Levin" <ldv@...linux.org>,
	v9fs-developer@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-afs@...ts.infradead.org,
	linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	codalist@...emann.coda.cs.cmu.edu, ecryptfs@...r.kernel.org,
	osd-dev@...n-osd.org, linux-ext4@...r.kernel.org,
	fuse-devel@...ts.sourceforge.net, linux-mtd@...ts.infradead.org,
	jfs-discussion@...ts.sourceforge.net, logfs@...fs.org,
	linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org,
	linux-ntfs-dev@...ts.sourceforge.net, ocfs2-devel@....oracle.com,
	reiserfs-devel@...r.kernel.org
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from
 deactivate_locked_super() to filesystems

On Fri, Jun 8, 2012 at 4:37 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> 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 thing is, none of the inode caches are really up to the VFS. They
are per-filesystem caches, that just *embed* an inode as part of the
bigger ext4_inode or whatever. But apart from the fact that the
embedded inode requires them to then use the proper "call_rcu()" stuff
to do the delayed free, they really are pretty much filesystem data
structures. The VFS layer can neither free them or allocate them,
since the VFS layer doesn't even know how big the structures are, or
where the inodes are embedded, or how to initialize them (or even when
to allocate them).

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.

                Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html