1. 25 7月, 2008 4 次提交
    • I
      autofs4: fix symlink name allocation · ef581a74
      Ian Kent 提交于
      The length of the symlink name has been moved but it needs to be set
      before allocating space for it in the dentry info struct.  This corrects a
      mistake in a recent patch.
      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>
      ef581a74
    • I
      autofs4: use look aside list for lookups · 25767378
      Ian Kent 提交于
      A while ago a patch to resolve a deadlock during directory creation was
      merged.  This delayed the hashing of lookup dentrys until the ->mkdir()
      (or ->symlink()) operation completed to ensure we always went through
      ->lookup() instead of also having processes go through ->revalidate() so
      our VFS locking remained consistent.
      
      Now we are seeing a couple of side affects of that change in situations
      with heavy mount activity.
      
      Two cases have been identified:
      
      1) When a mount request is triggered, due to the delayed hashing, the
         directory created by user space for the mount point doesn't have the
         DCACHE_AUTOFS_PENDING flag set.  In the case of an autofs multi-mount
         where a tree of mount point directories are created this can lead to
         the path walk continuing rather than the dentry being sent to the wait
         queue to wait for request completion.  This is because, if the pending
         flag isn't set, the criteria for deciding this is a mount in progress
         fails to hold, namely that the dentry is not a mount point and has no
         subdirectories.
      
      2) A mount request dentry is initially created negative and unhashed.
         It remains this way until the ->mkdir() callback completes.  Since it
         is unhashed a fresh dentry is used when the user space mount request
         creates the mount point directory.  This leaves the original dentry
         negative and unhashed.  But revalidate has no way to tell the VFS that
         the dentry has changed, other than to force another ->lookup() by
         returning false, which is at best wastefull and at worst not possible.
         This results in an -ENOENT return from the original path walk when in
         fact the mount succeeded.
      
      To resolve this we need to ensure that the same dentry is used in all
      calls to ->lookup() during the course of a mount request.  This patch
      achieves that by adding the initial dentry to a look aside list and
      removes it at ->mkdir() or ->symlink() completion (or when the dentry is
      released), since these are the only create operations autofs4 supports.
      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>
      25767378
    • I
      autofs4: revert - redo lookup in ttfd · caf7da3d
      Ian Kent 提交于
      This patch series enables the use of a single dentry for lookups prior to
      the dentry being hashed and so we no longer need to redo the lookup.  This
      patch reverts the patch of commit
      03379044.
      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>
      caf7da3d
    • I
      autofs4: don't make expiring dentry negative · 5f6f4f28
      Ian Kent 提交于
      Correct the error of making a positive dentry negative after it has been
      instantiated.
      
      The code that makes this error attempts to re-use the dentry from a
      concurrent expire and mount to resolve a race and the dentry used for the
      lookup must be negative for mounts to trigger in the required cases.  The
      fact is that the dentry doesn't need to be re-used because all that is
      needed is to preserve the flag that indicates an expire is still
      incomplete at the time of the mount request.
      
      This change uses the the dentry to check the flag and wait for the expire
      to complete then discards it instead of attempting to re-use it.
      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>
      5f6f4f28
  2. 01 5月, 2008 3 次提交
    • J
      autofs: path_{get,put}() cleanups · 868eb7a8
      Jan Blunck 提交于
      Here are some more places where path_{get,put}() can be used instead of
      dput()/mntput() pair.  Besides that it fixes a bug in autofs4_mount_busy()
      where mntput() was called before dput().
      Signed-off-by: NJan Blunck <jblunck@suse.de>
      Cc: Ian Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      868eb7a8
    • J
      autofs4: fix incorrect return from root.c:try_to_fill_dentry() · 9d2de6ad
      Jeff Moyer 提交于
      Jeff Moyer has identified a case where the autofs4 function
      root.c:try_to_fill_dentry() can return -EBUSY when it should return 0.
      
      Jeff's description of the way this happens is:
      
      "automount starts an expire for directory d.  after the callout to the daemon,
      but before the rmdir, another process tries to walk into the same directory.
      It puts itself onto the waitq, pending the expiration.
      
      When the expire finishes, the second process is woken up.  In
      try_to_fill_dentry, it does this check:
      
                      status = d_invalidate(dentry);
                      if (status != -EBUSY)
                              return -EAGAIN;
      
      And status is EBUSY.  The dentry still has a non-zero d_inode, and the
      flags do not contain LOOKUP_CONTINUE or LOOKUP_DIRECTORY
      
      So, we fall through and return -EBUSY to the caller."
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      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>
      9d2de6ad
    • 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
  3. 29 4月, 2008 1 次提交
  4. 15 2月, 2008 2 次提交
  5. 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
  6. 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
  7. 11 5月, 2007 1 次提交
  8. 09 5月, 2007 1 次提交
  9. 13 4月, 2007 1 次提交
  10. 21 2月, 2007 2 次提交
  11. 13 2月, 2007 1 次提交
  12. 09 12月, 2006 1 次提交
  13. 01 10月, 2006 3 次提交
  14. 30 9月, 2006 2 次提交
  15. 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
  16. 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
  17. 29 3月, 2006 1 次提交
  18. 28 3月, 2006 10 次提交
  19. 15 1月, 2006 1 次提交
  20. 12 1月, 2006 1 次提交
  21. 11 1月, 2006 1 次提交