xfs
[Top] [All Lists]

Re: [PATCH v18 11/22] vfs: Cache base_acl objects in inodes

To: Andreas Gruenbacher <agruenba@xxxxxxxxxx>
Subject: Re: [PATCH v18 11/22] vfs: Cache base_acl objects in inodes
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 15 Mar 2016 00:12:56 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, Linux NFS Mailing List <linux-nfs@xxxxxxxxxxxxxxx>, Theodore Ts'o <tytso@xxxxxxx>, linux-cifs@xxxxxxxxxxxxxxx, Linux API <linux-api@xxxxxxxxxxxxxxx>, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, XFS Developers <xfs@xxxxxxxxxxx>, Andreas Dilger <adilger.kernel@xxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, Jeff Layton <jlayton@xxxxxxxxxxxxxxx>, linux-ext4 <linux-ext4@xxxxxxxxxxxxxxx>, Anna Schumaker <anna.schumaker@xxxxxxxxxx>, jaegeuk@xxxxxxxxxx, chao2.yu@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAHc6FU7hSDBa51mJZZZ=q3agzWXk=DZicnyuPriKHnC2Nxr8rw@xxxxxxxxxxxxxx>
References: <1456733847-17982-1-git-send-email-agruenba@xxxxxxxxxx> <1456733847-17982-12-git-send-email-agruenba@xxxxxxxxxx> <20160311140746.GC14808@xxxxxxxxxxxxx> <CAHc6FU7hSDBa51mJZZZ=q3agzWXk=DZicnyuPriKHnC2Nxr8rw@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.24 (2015-08-30)
On Fri, Mar 11, 2016 at 05:24:45PM +0100, Andreas Gruenbacher wrote:
> POSIX ACLs and RichACLs are different objects, with different members
> and different algorithms operating on them. The only commonality is
> that they are both kmalloc()ed, reference counted objects, and when an
> inode is destroyed, both kinds of ACLs can be put in the same way,
> avoiding an unnecessary if. What kind of common-code container beyond
> that are you still dreaming about?

We still have a main object that is simply a list of ACEs.  But if that
doesn't work out (I suspect it should) I don't think the common base
object is a good idea.  It just leads to a lot of crazy container_of
calls.  If the common object abstraction doesn't work out we'll need
a procedural one instead that has common acl_* calls that decide what
do to based on the file system acl flag.

<Prev in Thread] Current Thread [Next in Thread>