1. 09 Jun, 2009 1 commit
    • Ian Kent's avatar
      autofs4: remove hashed check in validate_wait() · 463aea1a
      Ian Kent authored
      
      
      The recent ->lookup() deadlock correction required the directory inode
      mutex to be dropped while waiting for expire completion.  We were
      concerned about side effects from this change and one has been identified.
      
      I saw several error messages.
      
      They cause autofs to become quite confused and don't really point to the
      actual problem.
      
      Things like:
      
      handle_packet_missing_direct:1376: can't find map entry for (43,1827932)
      
      which is usually totally fatal (although in this case it wouldn't be
      except that I treat is as such because it normally is).
      
      do_mount_direct: direct trigger not valid or already mounted
      /test/nested/g3c/s1/ss1
      
      which is recoverable, however if this problem is at play it can cause
      autofs to become quite confused as to the dependencies in the mount tree
      because mount triggers end up mounted multiple times.  It's hard to
      accurately check for this over mounting case and automount shouldn't need
      to if the kernel module is doing its job.
      
      There was one other message, similar in consequence of this last one but I
      can't locate a log example just now.
      
      When checking if a mount has already completed prior to adding a new mount
      request to the wait queue we check if the dentry is hashed and, if so, if
      it is a mount point.  But, if a mount successfully completed while we
      slept on the wait queue mutex the dentry must exist for the mount to have
      completed so the test is not really needed.
      
      Mounts can also be done on top of a global root dentry, so for the above
      case, where a mount request completes and the wait queue entry has already
      been removed, the hashed test returning false can cause an incorrect
      callback to the daemon.  Also, d_mountpoint() is not sufficient to check
      if a mount has completed for the multi-mount case when we don't have a
      real mount at the base of the tree.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      463aea1a
  2. 06 Jan, 2009 1 commit
    • Ian Kent's avatar
      autofs4: make autofs type usage explicit · a92daf6b
      Ian Kent authored
      
      
      - the type assigned at mount when no type is given is changed
        from 0 to AUTOFS_TYPE_INDIRECT. This was done because 0 and
        AUTOFS_TYPE_INDIRECT were being treated implicitly as the same
        type.
      
      - previously, an offset mount had it's type set to
        AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET but the mount control
        re-implementation needs to be able distinguish all three types.
        So this was changed to make the type setting explicit.
      
      - a type AUTOFS_TYPE_ANY was added for use by the re-implementation
        when checking if a given path is a mountpoint. It's not really a
        type as we use this to ask if a given path is a mountpoint in the
        autofs_dev_ioctl_ismountpoint() function.
      
      - functions to set and test the autofs mount types have been added to
        improve readability and make the type usage explicit.
      
      - the mount type is used from user space for the mount control
        re-implementtion so, for consistency, all the definitions have
        been moved to the user space include file include/linux/auto_fs4.h.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a92daf6b
  3. 13 Nov, 2008 1 commit
  4. 16 Oct, 2008 2 commits
  5. 24 Jul, 2008 8 commits
    • Ian Kent's avatar
      autofs4: indirect dentry must almost always be positive · c72305b5
      Ian Kent authored
      
      
      We have been seeing mount requests comming to the automount daemon for
      keys of the form "<map key>/<non key directory>" which are lookups for
      invalid map keys.  But we can check for this in the kernel module and
      return a fail immediately, without having to send a request to the daemon.
      
      It is possible to recognise these requests are invalid based on whether
      the request dentry is negative and its relation to the autofs file system
      root.
      
      For example, given the indirect multi-mount map entry:
      
      idm1  \
          /mm1  <server>:/<path1>
          /mm2  <server>:/<path2>
      
      For a request to mount idm1, IS_ROOT((idm1)->d_parent) will be always be
      true and the dentry may be negative.  But directories idm1/mm1 and
      idm1/mm2 will always be created as part of the mount request for idm1.  So
      any mount request within idm1 itself must have a positive dentry otherwise
      the map key is invalid.
      
      In version 4 these multi-mount entries are all mounted and umounted as a
      single request and in version 5 the directories idm1/mm1 and idm1/mm2 are
      created and an autofs fs mounted on them to act as a mount trigger so the
      above is also true.
      
      This also holds true for the autofs version 4 pseudo direct mount feature.
       When this feature is used without the "--ghost" option automount(8) will
      create internal submounts as we go down the map key paths which are
      essentially normal indirect mounts for which the above holds.  If the
      "--ghost" option is given the directories for map keys are created at
      daemon startup so valid map entries correspond to postive dentries in the
      autofs fs.
      
      autofs version 5 direct mount maps are similar except that the IS_ROOT
      check is not needed.  This has been addressed in a previous patch tittled
      "autofs4 - detect invalid direct mount requests".
      
      For example, given the direct multi-mount map entry:
      
      /test/dm1  \
          /mm1  <server>:/<path1>
          /mm2  <server>:/<path2>
      
      An autofs fs is mounted on /test/dm1 as a trigger mount and when a mount
      is triggered for /test/dm1, the multi-mount offset directories
      /test/dm1/mm1 and /test/dm1/mm2 are created and an autofs fs is mounted on
      them to act as mount triggers.  So valid direct mount requests must always
      have a positive dentry if they correspond to a valid map entry.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Acked-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c72305b5
    • Ian Kent's avatar
      autofs4: detect invalid direct mount requests · eb3b1767
      Ian Kent authored
      
      
      autofs v5 direct and offset mounts within an autofs filesystem are
      triggered by existing autofs triger mounts so the mount point dentry must
      be positive.  If the mount point dentry is negative then the trigger
      doesn't exist so we can return fail immediately.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eb3b1767
    • Ian Kent's avatar
      autofs4: fix waitq memory leak · 296f7bf7
      Ian Kent authored
      
      
      If an autofs mount becomes catatonic before autofs4_wait_release() is
      called the wait queue counter will not be decremented down to zero and the
      entry will never be freed.  There are also races decrementing the wait
      counter in the wait release function.  To deal with this the counter needs
      to be updated while holding the wait queue mutex and waiters need to be
      woken up unconditionally when the wait is removed from the queue to ensure
      we eventually free the wait.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      296f7bf7
    • Ian Kent's avatar
      autofs4: check kernel communication pipe is valid for write · e64be33c
      Ian Kent authored
      
      
      It is possible for an autofs mount to become catatonic (and for the daemon
      communication pipe to become NULL) after a wait has been initiallized but
      before the request has been sent to the daemon.  We need to check for this
      before sending the request packet.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e64be33c
    • Ian Kent's avatar
      autofs4: add missing kfree · f4c7da02
      Ian Kent authored
      
      
      It see that the patch tittled "autofs4 - fix pending mount race" is
      missing a change that I had recently made.
      
      It's missing a kfree for the case mutex_lock_interruptible() fails
      to aquire the wait queue mutex.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f4c7da02
    • Ian Kent's avatar
      autofs4: fix pending mount race · a1362fe9
      Ian Kent authored
      
      
      Close a race between a pending mount that is about to finish and a new
      lookup for the same directory.
      
      Process P1 triggers a mount of directory foo.  It sets
      DCACHE_AUTOFS_PENDING in the ->lookup routine, creates a waitq entry for
      'foo', and calls out to the daemon to perform the mount.  The autofs
      daemon will then create the directory 'foo', using a new dentry that will
      be hashed in the dcache.
      
      Before the mount completes, another process, P2, tries to walk into the
      'foo' directory.  The vfs path walking code finds an entry for 'foo' and
      calls the revalidate method.  Revalidate finds that the entry is not
      PENDING (because PENDING was never set on the dentry created by the
      mkdir), but it does find the directory is empty.  Revalidate calls
      try_to_fill_dentry, which sets the PENDING flag and then calls into the
      autofs4 wait code to trigger or wait for a mount of 'foo'.  The wait code
      finds the entry for 'foo' and goes to sleep waiting for the completion of
      the mount.
      
      Yet another process, P3, tries to walk into the 'foo' directory.  This
      process again finds a dentry in the dcache for 'foo', and calls into the
      autofs revalidate code.
      
      The revalidate code finds that the PENDING flag is set, and so calls
      try_to_fill_dentry.
      
      a) try_to_fill_dentry sets the PENDING flag redundantly for this
         dentry, then calls into the autofs4 wait code.
      
      b) the autofs4 wait code takes the waitq mutex and searches for an
         entry for 'foo'
      
      Between a and b, P1 is woken up because the mount completed.  P1 takes the
      wait queue mutex, clears the PENDING flag from the dentry, and removes the
      waitqueue entry for 'foo' from the list.
      
      When it releases the waitq mutex, P3 (eventually) acquires it.  At this
      time, it looks for an existing waitq for 'foo', finds none, and so creates
      a new one and calls out to the daemon to mount the 'foo' directory.
      
      Now, the reason that three processes are required to trigger this race is
      that, because the PENDING flag is not set on the dentry created by mkdir,
      the window for the race would be way to slim for it to ever occur.
      Basically, between the testing of d_mountpoint(dentry) and the taking of
      the waitq mutex, the mount would have to complete and the daemon would
      have to be woken up, and that in turn would have to wake up P1.  This is
      simply impossible.  Add the third process, though, and it becomes slightly
      more likely.
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1362fe9
    • Ian Kent's avatar
      autofs4: fix waitq locking · 5a11d4d0
      Ian Kent authored
      
      
      The autofs4_catatonic_mode() function accesses the wait queue without any
      locking but can be called at any time.  This could lead to a possible
      double free of the name field of the wait and a double fput of the daemon
      communication pipe or an fput of a NULL file pointer.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5a11d4d0
    • Jeff Moyer's avatar
      autofs4: use struct qstr in waitq.c · 70b52a0a
      Jeff Moyer authored
      
      
      The autofs_wait_queue already contains all of the fields of the
      struct qstr, so change it into a qstr.
      
      This patch, from Jeff Moyer, has been modified a liitle by myself.
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70b52a0a
  6. 01 May, 2008 1 commit
  7. 18 Oct, 2007 1 commit
  8. 21 Feb, 2007 1 commit
  9. 14 Nov, 2006 1 commit
  10. 11 Oct, 2006 1 commit
  11. 15 May, 2006 1 commit
    • Ian Kent's avatar
      [PATCH] autofs4: NFY_NONE wait race fix · a5370553
      Ian Kent authored
      
      
      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: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a5370553
  12. 27 Mar, 2006 4 commits
  13. 23 Mar, 2006 1 commit
  14. 07 Nov, 2005 1 commit
  15. 08 Jul, 2005 1 commit
  16. 22 Jun, 2005 1 commit
    • Ian Kent's avatar
      [PATCH] autofs4: post expire race fix · cc9acc88
      Ian Kent authored
      
      
      At the tail end of an expire it's possible for a process to enter
      autofs4_wait, with a waitq type of NFY_NONE but find that the expire is
      finished.  In this cause autofs4_wait will try to create a new wait but not
      notify the daemon leading to a hang.  As the wait type is meant to delay mount
      requests from revalidate or lookup during an expire and the expire is done all
      we need to do is check if the dentry is a mountpoint.  If it's not then we're
      done.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cc9acc88
  17. 01 May, 2005 1 commit
  18. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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