1. 11 8月, 2010 1 次提交
  2. 10 8月, 2010 1 次提交
  3. 15 5月, 2010 1 次提交
    • A
      Fix the regression created by "set S_DEAD on unlink()..." commit · d83c49f3
      Al Viro 提交于
      1) i_flags simply doesn't work for mount/unlink race prevention;
      we may have many links to file and rm on one of those obviously
      shouldn't prevent bind on top of another later on.  To fix it
      right way we need to mark _dentry_ as unsuitable for mounting
      upon; new flag (DCACHE_CANT_MOUNT) is protected by d_flags and
      i_mutex on the inode in question.  Set it (with dont_mount(dentry))
      in unlink/rmdir/etc., check (with cant_mount(dentry)) in places
      in namespace.c that used to check for S_DEAD.  Setting S_DEAD
      is still needed in places where we used to set it (for directories
      getting killed), since we rely on it for readdir/rmdir race
      prevention.
      
      2) rename()/mount() protection has another bogosity - we unhash
      the target before we'd checked that it's not a mountpoint.  Fixed.
      
      3) ancient bogosity in pivot_root() - we locked i_mutex on the
      right directory, but checked S_DEAD on the different (and wrong)
      one.  Noticed and fixed.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d83c49f3
  4. 12 6月, 2009 3 次提交
  5. 28 3月, 2009 1 次提交
  6. 01 1月, 2009 1 次提交
    • N
      shrink struct dentry · c2452f32
      Nick Piggin 提交于
      struct dentry is one of the most critical structures in the kernel. So it's
      sad to see it going neglected.
      
      With CONFIG_PROFILING turned on (which is probably the common case at least
      for distros and kernel developers), sizeof(struct dcache) == 208 here
      (64-bit). This gives 19 objects per slab.
      
      I packed d_mounted into a hole, and took another 4 bytes off the inline
      name length to take the padding out from the end of the structure. This
      shinks it to 200 bytes. I could have gone the other way and increased the
      length to 40, but I'm aiming for a magic number, read on...
      
      I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
      why was this ever a good idea? The cookie system should increase its hash
      size or use a tree or something if lookups are a problem. Also the "fast
      dcookie lookups" in oprofile should be moved into the dcookie code -- how
      can oprofile possibly care about the dcookie_mutex? It gets dropped after
      get_dcookie() returns so it can't be providing any sort of protection.
      
      At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
      with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
      nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
      will now require 3 cachelines to touch all fields wheras previously it
      would require 4.
      
      I know the inline name size was chosen quite carefully, however with the
      reduction in cacheline footprint, it should actually be just about as fast
      to do a name lookup for a 36 character name as it was before the patch (and
      faster for other sizes). The memory footprint savings for names which are
      <= 32 or > 36 bytes long should more than make up for the memory cost for
      33-36 byte names.
      
      Performance is a feature...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c2452f32
  7. 23 10月, 2008 3 次提交
  8. 25 8月, 2008 1 次提交
  9. 28 7月, 2008 1 次提交
  10. 23 6月, 2008 1 次提交
  11. 19 5月, 2008 1 次提交
  12. 30 4月, 2008 1 次提交
  13. 23 4月, 2008 2 次提交
  14. 22 4月, 2008 1 次提交
  15. 15 2月, 2008 1 次提交
  16. 21 10月, 2007 1 次提交
    • A
      [PATCH] audit: watching subtrees · 74c3cbe3
      Al Viro 提交于
      New kind of audit rule predicates: "object is visible in given subtree".
      The part that can be sanely implemented, that is.  Limitations:
      	* if you have hardlink from outside of tree, you'd better watch
      it too (or just watch the object itself, obviously)
      	* if you mount something under a watched tree, tell audit
      that new chunk should be added to watched subtrees
      	* if you umount something in a watched tree and it's still mounted
      elsewhere, you will get matches on events happening there.  New command
      tells audit to recalculate the trees, trimming such sources of false
      positives.
      
      Note that it's _not_ about path - if something mounted in several places
      (multiple mount, bindings, different namespaces, etc.), the match does
      _not_ depend on which one we are using for access.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      74c3cbe3
  17. 09 5月, 2007 1 次提交
    • E
      VFS: delay the dentry name generation on sockets and pipes · c23fbb6b
      Eric Dumazet 提交于
      1) Introduces a new method in 'struct dentry_operations'.  This method
         called d_dname() might be called from d_path() to build a pathname for
         special filesystems.  It is called without locks.
      
         Future patches (if we succeed in having one common dentry for all
         pipes/sockets) may need to change prototype of this method, but we now
         use : char *d_dname(struct dentry *dentry, char *buffer, int buflen);
      
      2) Adds a dynamic_dname() helper function that eases d_dname() implementations
      
      3) Defines d_dname method for sockets : No more sprintf() at socket
         creation.  This is delayed up to the moment someone does an access to
         /proc/pid/fd/...
      
      4) Defines d_dname method for pipes : No more sprintf() at pipe
         creation.  This is delayed up to the moment someone does an access to
         /proc/pid/fd/...
      
      A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a
      *nice* speedup on my Pentium(M) 1.6 Ghz :
      
      3.090 s instead of 3.450 s
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Acked-by: NChristoph Hellwig <hch@infradead.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c23fbb6b
  18. 12 10月, 2006 1 次提交
    • D
      [PATCH] VFS: Destroy the dentries contributed by a superblock on unmounting · c636ebdb
      David Howells 提交于
      The attached patch destroys all the dentries attached to a superblock in one go
      by:
      
       (1) Destroying the tree rooted at s_root.
      
       (2) Destroying every entry in the anon list, one at a time.
      
       (3) Each entry in the anon list has its subtree consumed from the leaves
           inwards.
      
      This reduces the amount of work generic_shutdown_super() does, and avoids
      iterating through the dentry_unused list.
      
      Note that locking is almost entirely absent in the shrink_dcache_for_umount*()
      functions added by this patch.  This is because:
      
       (1) at the point the filesystem calls generic_shutdown_super(), it is not
           permitted to further touch the superblock's set of dentries, and nor may
           it remove aliases from inodes;
      
       (2) the dcache memory shrinker now skips dentries that are being unmounted;
           and
      
       (3) the superblock no longer has any external references through which the VFS
           can reach it.
      
      Given these points, the only locking we need to do is when we remove dentries
      from the unused list and the name hashes, which we do a directory's worth at a
      time.
      
      We also don't need to guard against reference counts going to zero unexpectedly
      and removing bits of the tree we're working on as nothing else can call dput().
      
      A cut down version of dentry_iput() has been folded into
      shrink_dcache_for_umount_subtree() function.  Apart from not needing to unlock
      things, it also doesn't need to check for inotify watches.
      
      In this version of the patch, the complaint about a dentry still being in use
      has been expanded from a single BUG_ON() and now gives much more information.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      Acked-by: NIan Kent <raven@themaw.net>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c636ebdb
  19. 23 9月, 2006 1 次提交
    • D
      NFS: Add dentry materialisation op · 770bfad8
      David Howells 提交于
      The attached patch adds a new directory cache management function that prepares
      a disconnected anonymous function to be connected into the dentry tree. The
      anonymous dentry is transferred the name and parentage from another dentry.
      
      The following changes were made in [try #2]:
      
       (*) d_materialise_dentry() now switches the parentage of the two nodes around
           correctly when one or other of them is self-referential.
      
      The following changes were made in [try #7]:
      
       (*) d_instantiate_unique() has had the interior part split out as function
           __d_instantiate_unique(). Callers of this latter function must be holding
           the appropriate locks.
      
       (*) _d_rehash() has been added as a wrapper around __d_rehash() to call it
           with the most obvious hash list (the one from the name). d_rehash() now
           calls _d_rehash().
      
       (*) d_materialise_dentry() is now __d_materialise_dentry() and is static.
      
       (*) d_materialise_unique() added to perform the combination of d_find_alias(),
           d_materialise_dentry() and d_add_unique() that the NFS client was doing
           twice, all within a single dcache_lock critical section. This reduces the
           number of times two different spinlocks were being accessed.
      
      The following further changes were made:
      
       (*) Add the dentries onto their parents d_subdirs lists.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      770bfad8
  20. 04 7月, 2006 1 次提交
  21. 23 6月, 2006 2 次提交
    • D
      [PATCH] VFS: Permit filesystem to override root dentry on mount · 454e2398
      David Howells 提交于
      Extend the get_sb() filesystem operation to take an extra argument that
      permits the VFS to pass in the target vfsmount that defines the mountpoint.
      
      The filesystem is then required to manually set the superblock and root dentry
      pointers.  For most filesystems, this should be done with simple_set_mnt()
      which will set the superblock pointer and then set the root dentry to the
      superblock's s_root (as per the old default behaviour).
      
      The get_sb() op now returns an integer as there's now no need to return the
      superblock pointer.
      
      This patch permits a superblock to be implicitly shared amongst several mount
      points, such as can be done with NFS to avoid potential inode aliasing.  In
      such a case, simple_set_mnt() would not be called, and instead the mnt_root
      and mnt_sb would be set directly.
      
      The patch also makes the following changes:
      
       (*) the get_sb_*() convenience functions in the core kernel now take a vfsmount
           pointer argument and return an integer, so most filesystems have to change
           very little.
      
       (*) If one of the convenience function is not used, then get_sb() should
           normally call simple_set_mnt() to instantiate the vfsmount. This will
           always return 0, and so can be tail-called from get_sb().
      
       (*) generic_shutdown_super() now calls shrink_dcache_sb() to clean up the
           dcache upon superblock destruction rather than shrink_dcache_anon().
      
           This is required because the superblock may now have multiple trees that
           aren't actually bound to s_root, but that still need to be cleaned up. The
           currently called functions assume that the whole tree is rooted at s_root,
           and that anonymous dentries are not the roots of trees which results in
           dentries being left unculled.
      
           However, with the way NFS superblock sharing are currently set to be
           implemented, these assumptions are violated: the root of the filesystem is
           simply a dummy dentry and inode (the real inode for '/' may well be
           inaccessible), and all the vfsmounts are rooted on anonymous[*] dentries
           with child trees.
      
           [*] Anonymous until discovered from another tree.
      
       (*) The documentation has been adjusted, including the additional bit of
           changing ext2_* into foo_* in the documentation.
      
      [akpm@osdl.org: convert ipath_fs, do other stuff]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Nathan Scott <nathans@sgi.com>
      Cc: Roland Dreier <rolandd@cisco.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      454e2398
    • N
      [PATCH] Fix dcache race during umount · 0feae5c4
      NeilBrown 提交于
      The race is that the shrink_dcache_memory shrinker could get called while a
      filesystem is being unmounted, and could try to prune a dentry belonging to
      that filesystem.
      
      If it does, then it will call in to iput on the inode while the dentry is
      no longer able to be found by the umounting process.  If iput takes a
      while, generic_shutdown_super could get all the way though
      shrink_dcache_parent and shrink_dcache_anon and invalidate_inodes without
      ever waiting on this particular inode.
      
      Eventually the superblock gets freed anyway and if the iput tried to touch
      it (which some filesystems certainly do), it will lose.  The promised
      "Self-destruct in 5 seconds" doesn't lead to a nice day.
      
      The race is closed by holding s_umount while calling prune_one_dentry on
      someone else's dentry.  As a down_read_trylock is used,
      shrink_dcache_memory will no longer try to prune the dentry of a filesystem
      that is being unmounted, and unmount will not be able to start until any
      such active prune_one_dentry completes.
      
      This requires that prune_dcache *knows* which filesystem (if any) it is
      doing the prune on behalf of so that it can be careful of other
      filesystems.  shrink_dcache_memory isn't called it on behalf of any
      filesystem, and so is careful of everything.
      
      shrink_dcache_anon is now passed a super_block rather than the s_anon list
      out of the superblock, so it can get the s_anon list itself, and can pass
      the superblock down to prune_dcache.
      
      If prune_dcache finds a dentry that it cannot free, it leaves it where it
      is (at the tail of the list) and exits, on the assumption that some other
      thread will be removing that dentry soon.  To try to make sure that some
      work gets done, a limited number of dnetries which are untouchable are
      skipped over while choosing the dentry to work on.
      
      I believe this race was first found by Kirill Korotaev.
      
      Cc: Jan Blunck <jblunck@suse.de>
      Acked-by: NKirill Korotaev <dev@openvz.org>
      Cc: Olaf Hering <olh@suse.de>
      Acked-by: NBalbir Singh <balbir@in.ibm.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NBalbir Singh <balbir@in.ibm.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0feae5c4
  22. 01 4月, 2006 1 次提交
  23. 26 3月, 2006 1 次提交
    • N
      [PATCH] inotify: lock avoidance with parent watch status in dentry · c32ccd87
      Nick Piggin 提交于
      Previous inotify work avoidance is good when inotify is completely unused,
      but it breaks down if even a single watch is in place anywhere in the
      system.  Robin Holt notices that udev is one such culprit - it slows down a
      512-thread application on a 512 CPU system from 6 seconds to 22 minutes.
      
      Solve this by adding a flag in the dentry that tells inotify whether or not
      its parent inode has a watch on it.  Event queueing to parent will skip
      taking locks if this flag is cleared.  Setting and clearing of this flag on
      all child dentries versus event delivery: this is no in terms of race
      cases, and that was shown to be equivalent to always performing the check.
      
      The essential behaviour is that activity occuring _after_ a watch has been
      added and _before_ it has been removed, will generate events.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Robert Love <rml@novell.com>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c32ccd87
  24. 08 2月, 2006 1 次提交
  25. 04 2月, 2006 1 次提交
  26. 09 1月, 2006 1 次提交
    • E
      [PATCH] shrink dentry struct · 5160ee6f
      Eric Dumazet 提交于
      Some long time ago, dentry struct was carefully tuned so that on 32 bits
      UP, sizeof(struct dentry) was exactly 128, ie a power of 2, and a multiple
      of memory cache lines.
      
      Then RCU was added and dentry struct enlarged by two pointers, with nice
      results for SMP, but not so good on UP, because breaking the above tuning
      (128 + 8 = 136 bytes)
      
      This patch reverts this unwanted side effect, by using an union (d_u),
      where d_rcu and d_child are placed so that these two fields can share their
      memory needs.
      
      At the time d_free() is called (and d_rcu is really used), d_child is known
      to be empty and not touched by the dentry freeing.
      
      Lockless lookups only access d_name, d_parent, d_lock, d_op, d_flags (so
      the previous content of d_child is not needed if said dentry was unhashed
      but still accessed by a CPU because of RCU constraints)
      
      As dentry cache easily contains millions of entries, a size reduction is
      worth the extra complexity of the ugly C union.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: Maneesh Soni <maneesh@in.ibm.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: James Morris <jmorris@namei.org>
      Cc: Stephen Smalley <sds@epoch.ncsc.mil>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5160ee6f
  27. 08 11月, 2005 1 次提交
  28. 08 9月, 2005 1 次提交
    • E
      [PATCH] struct dentry: place d_hash close to d_parent and d_name to speedup lookups · 3f4bb1f4
      Eric Dumazet 提交于
      dentry cache uses sophisticated RCU technology (and prefetching if
      available) but touches 2 cache lines per dentry during hlist lookup.
      
      This patch moves d_hash in the same cache line than d_parent and d_name
      fields so that :
      
      1) One cache line is needed instead of two.
      
      2) the hlist_for_each_rcu() prefetching has a chance to bring all the
         needed data in advance, not only the part that includes d_hash.next.
      
      I also changed one old comment that was wrong for 64bits.
      
      A further optimisation would be to separate dentry in two parts, one that
      is mostly read, and one writen (d_count/d_lock) to avoid false sharing on
      SMP/NUMA but this would need different field placement depending on 32bits
      or 64bits platform.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f4bb1f4
  29. 17 4月, 2005 1 次提交
    • 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