1. 17 10月, 2008 2 次提交
    • I
      autofs4: add miscellaneous device for ioctls · 8d7b48e0
      Ian Kent 提交于
      Add a miscellaneous device to the autofs4 module for routing ioctls.  This
      provides the ability to obtain an ioctl file handle for an autofs mount
      point that is possibly covered by another mount.
      
      The actual problem with autofs is that it can't reconnect to existing
      mounts.  Immediately one things of just adding the ability to remount
      autofs file systems would solve it, but alas, that can't work.  This is
      because autofs direct mounts and the implementation of "on demand mount
      and expire" of nested mount trees have the file system mounted on top of
      the mount trigger dentry.
      
      To resolve this a miscellaneous device node for routing ioctl commands to
      these mount points has been implemented in the autofs4 kernel module and a
      library added to autofs.  This provides the ability to open a file
      descriptor for these over mounted autofs mount points.
      
      Please refer to Documentation/filesystems/autofs4-mount-control.txt for a
      discussion of the problem, implementation alternatives considered and a
      description of the interface.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d7b48e0
    • I
      autofs4: cleanup autofs mount type usage · bb979d7f
      Ian Kent 提交于
      Usage of the AUTOFS_TYPE_* defines is a little confusing and appears
      inconsistent.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bb979d7f
  2. 25 7月, 2008 3 次提交
  3. 01 5月, 2008 2 次提交
  4. 26 9月, 2006 1 次提交
  5. 27 6月, 2006 1 次提交
  6. 26 6月, 2006 1 次提交
  7. 28 3月, 2006 8 次提交
  8. 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
  9. 22 6月, 2005 1 次提交
  10. 01 5月, 2005 1 次提交
  11. 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