1. 28 4月, 2009 1 次提交
    • L
      ext3: avoid unnecessary spinlock in critical POSIX ACL path · 96159f25
      Linus Torvalds 提交于
      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.
      
      ext3 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 is noticeable even on Nehalem, which does locking quite well (much 
      better than P4). From lmbench:
      
      	Processor, Processes - times in microseconds - smaller is better
      	--------------------------------------------------------------------
      	Host                 OS  Mhz null null      open slct fork exec sh  
      	                             call  I/O stat clos TCP  proc proc proc
      	--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ----
       - before:
      	nehalem.l Linux 2.6.30- 3193 0.04 0.09 0.95 1.45 2.18 69.1 273. 1141
      	nehalem.l Linux 2.6.30- 3193 0.04 0.09 0.95 1.48 2.28 69.9 253. 1140
      	nehalem.l Linux 2.6.30- 3193 0.04 0.10 0.95 1.42 2.19 68.6 284. 1141
       - after:
      	nehalem.l Linux 2.6.30- 3193 0.04 0.09 0.92 1.44 2.12 68.3 282. 1094
      	nehalem.l Linux 2.6.30- 3193 0.04 0.09 0.92 1.39 2.20 67.0 308. 1123
      	nehalem.l Linux 2.6.30- 3193 0.04 0.09 0.92 1.39 2.36 67.4 293. 1148
      
      where you can see what appears to be a roughly 3% improvement in stat
      and open/close latencies from just the removal of the locking overhead. 
      
      Of course, this only matters for files you don't own (the owner never 
      needs to do the ACL checks), but that's the common case for libraries, 
      header files, and executables. As well as for the base components of any 
      absolute pathname, even if you are the owner of the final file.
      
      [ At some point we probably want to move this ACL caching logic entirely
        into the VFS layer (and only call down to the filesystem when
        uncached), but in the meantime this improves ext3 a bit.
      
        A similar fix to btrfs makes a much bigger difference (15x improvement
        in lmbench) due to broken caching. ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Acked-by: NJan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      96159f25
  2. 01 4月, 2009 1 次提交
  3. 27 7月, 2008 1 次提交
    • A
      [PATCH] sanitize ->permission() prototype · e6305c43
      Al Viro 提交于
      * 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: NAl Viro <viro@zeniv.linux.org.uk>
      e6305c43
  4. 20 3月, 2008 1 次提交
  5. 18 7月, 2007 1 次提交
    • S
      Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check · 3bd858ab
      Satyam Sharma 提交于
      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: NSatyam Sharma <ssatyam@cse.iitk.ac.in>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: NSerge E. Hallyn <serge@hallyn.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3bd858ab
  6. 27 9月, 2006 2 次提交
  7. 04 2月, 2006 1 次提交
  8. 12 1月, 2006 1 次提交
  9. 10 1月, 2006 1 次提交
  10. 24 6月, 2005 2 次提交
  11. 17 4月, 2005 2 次提交
    • A
      [PATCH] Fix acl Oops · e493073d
      akpm@osdl.org 提交于
      )
      
      
      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: NAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e493073d
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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