Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 21 May, 2010 1 commit
  3. 16 Dec, 2009 1 commit
    • Christoph Hellwig's avatar
      sanitize xattr handler prototypes · 431547b3
      Christoph Hellwig authored 
      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 <swhiteho@redhat.com>]
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarJames Morris <jmorris@namei.org>
Acked-by: default avatarJoel Becker <joel.becker@oracle.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      431547b3
  5. 08 Sep, 2009 1 commit
  7. 24 Jun, 2009 2 commits
  9. 17 Jun, 2009 1 commit
    • Theodore Ts'o's avatar
      ext4: avoid unnecessary spinlock in critical POSIX ACL path · 210ad6ae
      Theodore Ts'o authored 
      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: default avatar"Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      210ad6ae
  11. 27 Apr, 2009 1 commit
    • Theodore Ts'o's avatar
      ext4: avoid unnecessary spinlock in critical POSIX ACL path · 8b0f9e8f
      Theodore Ts'o authored 
      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: default avatar"Theodore Ts'o" <tytso@mit.edu>
      8b0f9e8f
  13. 01 Apr, 2009 1 commit
  15. 27 Jul, 2008 1 commit
    • Al Viro's avatar
      [PATCH] sanitize ->permission() prototype · e6305c43
      Al Viro authored 
      * kill nameidata * argument; map the 3 bits in ->flags anybody cares
  about to new MAY_... ones and pass with the mask.
* kill redundant gfs2_iop_permission()
* sanitize ecryptfs_permission()
* fix remaining places where ->permission() instances might barf on new
  MAY_... found in mask.

The obvious next target in that direction is permission(9)

folded fix for nfs_permission() breakage from Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      e6305c43
  17. 26 Jul, 2008 1 commit
  19. 29 Apr, 2008 1 commit
  21. 30 Apr, 2008 1 commit
  23. 17 Jul, 2007 1 commit
    • Satyam Sharma's avatar
      Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check · 3bd858ab
      Satyam Sharma authored 
      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: default avatarSatyam Sharma <ssatyam@cse.iitk.ac.in>
Cc: Al Viro <viro@ftp.linux.org.uk>
Acked-by: default avatarSerge E. Hallyn <serge@hallyn.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3bd858ab
  25. 11 Oct, 2006 4 commits
  27. 27 Sep, 2006 2 commits
  29. 03 Feb, 2006 1 commit
  31. 12 Jan, 2006 1 commit
  33. 09 Jan, 2006 1 commit
  35. 24 Jun, 2005 1 commit
  37. 23 Jun, 2005 1 commit
  39. 16 Apr, 2005 2 commits
    • akpm@osdl.org's avatar
      [PATCH] Fix acl Oops · e493073d
      akpm@osdl.org authored 
      )


From: Andreas Gruenbacher <agruen@suse.de>

ext[23]_get_acl will return an error when reading the attribute fails or
out-of-memory occurs.  Catch this case.
Signed-off-by: default avatarAndreas Gruenbacher <agruen@suse.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e493073d
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7