Doug / smarc-fsl-linux-kernel

22 May, 2010

1 commit

17 Dec, 2009

1 commit

  • 431547b3c   sanitize xattr handler prototypes ... Browse Code »

    Add a flags argument to struct xattr_handler and pass it to all xattr
    handler methods. This allows using the same methods for multiple
    handlers, e.g. for the ACL methods which perform exactly the same action
    for the access and default ACLs, just using a different underlying
    attribute. With a little more groundwork it'll also allow sharing the
    methods for the regular user/trusted/secure handlers in extN, ocfs2 and
    jffs2 like it's already done for xfs in this patch.

    Also change the inode argument to the handlers to a dentry to allow
    using the handlers mechnism for filesystems that require it later,
    e.g. cifs.

    [with GFS2 bits updated by Steven Whitehouse ]

    Signed-off-by: Christoph Hellwig
    Reviewed-by: James Morris
    Acked-by: Joel Becker
    Signed-off-by: Al Viro

    Christoph Hellwig
     

09 Sep, 2009

1 commit

24 Jun, 2009

2 commits

17 Jun, 2009

1 commit

  • 210ad6aed   ext4: avoid unnecessary spinlock in critical POSIX ACL path ... Browse Code »

    If a filesystem supports POSIX ACL's, the VFS layer expects the filesystem
    to do POSIX ACL checks on any files not owned by the caller, and it does
    this for every single pathname component that it looks up.

    That obviously can be pretty expensive if the filesystem isn't careful
    about it, especially with locking. That's doubly sad, since the common
    case tends to be that there are no ACL's associated with the files in
    question.

    ext4 already caches the ACL data so that it doesn't have to look it up
    over and over again, but it does so by taking the inode->i_lock spinlock
    on every lookup. Which is a noticeable overhead even if it's a private
    lock, especially on CPU's where the serialization is expensive (eg Intel
    Netburst aka 'P4').

    For the special case of not actually having any ACL's, all that locking is
    unnecessary. Even if somebody else were to be changing the ACL's on
    another CPU, we simply don't care - if we've seen a NULL ACL, we might as
    well use it.

    So just load the ACL speculatively without any locking, and if it was
    NULL, just use it. If it's non-NULL (either because we had a cached
    entry, or because the cache hasn't been filled in at all), it means that
    we'll need to get the lock and re-load it properly.

    (This commit was ported from a patch originally authored by Linus for
    ext3.)

    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Al Viro

    Theodore Ts'o
     

01 Apr, 2009

1 commit

27 Jul, 2008

2 commits

30 Apr, 2008

2 commits

18 Jul, 2007

1 commit

  • 3bd858ab1   Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check ... Browse Code »

    Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
    users to it. This is done because we want to avoid bugs in the future
    where we check for only effective fsuid of the current task against a
    file's owning uid, without simultaneously checking for CAP_FOWNER as
    well, thus violating its semantics.
    [ XFS uses special macros and structures, and in general looked ...
    untouchable, so we leave it alone -- but it has been looked over. ]

    The (current->fsuid != inode->i_uid) check in generic_permission() and
    exec_permission_lite() is left alone, because those operations are
    covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
    falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.

    Signed-off-by: Satyam Sharma
    Cc: Al Viro
    Acked-by: Serge E. Hallyn
    Signed-off-by: Linus Torvalds

    Satyam Sharma
     

12 Oct, 2006

4 commits