1. 01 5月, 2008 1 次提交
    • J
      autofs4: fix execution order race in mount request code · 03379044
      Jeff Moyer 提交于
      Jeff Moyer has identified a race in due to an execution order dependency
      in the autofs4 function root.c:try_to_fill_dentry().
      
      Jeff's description of this race is:
      
      "P1 does a lookup of /mount/submount/foo.  Since the VFS can't find an entry
      for "foo" under /mount/submount, it calls into the autofs4 kernel module to
      allocate a new dentry, D1.  The kernel creates a new waitq for this lookup and
      calls the daemon to perform the mount.
      
      The daemon performs a mkdir of the "foo" directory under /mount/submount,
      which ends up creating a *new* dentry, D2.
      
      Then, P2 does a lookup of /mount/submount/foo.  The VFS path walking logic
      finds a dentry in the dcache, D2, and calls the revalidate function with this.
       In the autofs4 revalidate code, we then trigger a mount, since the dentry is
      an empty directory that isn't a mountpoint, and so set DCACHE_AUTOFS_PENDING
      and call into the wait code to trigger the mount.
      
      The wait code finds our existing waitq entry (since it is keyed off of the
      directory name) and adds itself to the list of waiters.
      
      After the daemon finishes the mount, it calls back into the kernel to release
      the waiters.  When this happens, P1 is woken up and goes about clearing the
      DCACHE_AUTOFS_PENDING flag, but it does this in D1!  So, given that P1 in our
      case is a program that will immediately try to access a file under
      /mount/submount/foo, we end up finding the dentry D2 which still has the
      pending flag set, and we set out to wait for a mount *again*!
      
      So, one way to address this is to re-do the lookup at the end of
      try_to_fill_dentry, and to clear the pending flag on the hashed dentry.  This
      seems a sane approach to me."
      
      And Jeff's patch does this.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      03379044
  2. 29 4月, 2008 1 次提交
  3. 15 2月, 2008 2 次提交
  4. 20 10月, 2007 1 次提交
    • P
      pid namespaces: round up the API · a47afb0f
      Pavel Emelianov 提交于
      The set of functions process_session, task_session, process_group and
      task_pgrp is confusing, as the names can be mixed with each other when looking
      at the code for a long time.
      
      The proposals are to
      * equip the functions that return the integer with _nr suffix to
        represent that fact,
      * and to make all functions work with task (not process) by making
        the common prefix of the same name.
      
      For monotony the routines signal_session() and set_signal_session() are
      replaced with task_session_nr() and set_task_session(), especially since they
      are only used with the explicit task->signal dereference.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a47afb0f
  5. 23 8月, 2007 1 次提交
    • I
      autofs4: deadlock during create · 1864f7bd
      Ian Kent 提交于
      Due to inconsistent locking in the VFS between calls to lookup and
      revalidate deadlock can occur in the automounter.
      
      The inconsistency is that the directory inode mutex is held for both lookup
      and revalidate calls when called via lookup_hash whereas it is held only
      for lookup during a path walk.  Consequently, if the mutex is held during a
      call to revalidate autofs4 can't release the mutex to callback the daemon
      as it can't know whether it owns the mutex.
      
      This situation happens when a process tries to create a directory within an
      automount and a second process also tries to create the same directory
      between the lookup and the mkdir.  Since the first process has dropped the
      mutex for the daemon callback, the second process takes it during
      revalidate leading to deadlock between the autofs daemon and the second
      process when the daemon tries to create the mount point directory.
      
      After spending quite a bit of time trying to resolve this on more than one
      occassion, using rather complex and ulgy approaches, it turns out that just
      delaying the hashing of the dentry until the create operation works fine.
      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>
      1864f7bd
  6. 11 5月, 2007 1 次提交
  7. 09 5月, 2007 1 次提交
  8. 13 4月, 2007 1 次提交
  9. 21 2月, 2007 2 次提交
  10. 13 2月, 2007 1 次提交
  11. 09 12月, 2006 1 次提交
  12. 01 10月, 2006 3 次提交
  13. 30 9月, 2006 2 次提交
  14. 27 9月, 2006 1 次提交
    • I
      [PATCH] autofs4 needs to force fail return revalidate · bcdc5e01
      Ian Kent 提交于
      For a long time now I have had a problem with not being able to return a
      lookup failure on an existsing directory.  In autofs this corresponds to a
      mount failure on a autofs managed mount entry that is browsable (and so the
      mount point directory exists).
      
      While this problem has been present for a long time I've avoided resolving
      it because it was not very visible.  But now that autofs v5 has "mount and
      expire on demand" of nested multiple mounts, such as is found when mounting
      an export list from a server, solving the problem cannot be avoided any
      longer.
      
      I've tried very hard to find a way to do this entirely within the autofs4
      module but have not been able to find a satisfactory way to achieve it.
      
      So, I need to propose a change to the VFS.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bcdc5e01
  15. 16 5月, 2006 1 次提交
    • I
      [PATCH] autofs4: NFY_NONE wait race fix · a5370553
      Ian Kent 提交于
      This patch fixes two problems.
      
      First, the comparison of entries in the waitq.c was incorrect.
      
      Second, the NFY_NONE check was incorrect. The test of whether the dentry
      is mounted if ineffective, for example, if an expire fails then we could
      wait forever on a non existant expire. The bug was identified by Jeff
      Moyer.
      
      The patch changes autofs4 to wait on expires only as this is all that's
      needed.  If there is no existing wait when autofs4_wait is call with a type
      of NFY_NONE it delays until either a wait appears or the the expire flag is
      cleared.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a5370553
  16. 29 3月, 2006 1 次提交
  17. 28 3月, 2006 10 次提交
  18. 15 1月, 2006 1 次提交
  19. 12 1月, 2006 1 次提交
  20. 11 1月, 2006 1 次提交
  21. 10 1月, 2006 1 次提交
  22. 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
  23. 22 6月, 2005 2 次提交
  24. 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