1. 28 Apr, 2012 1 commit
    • Linus Torvalds's avatar
      Revert "autofs: work around unhappy compat problem on x86-64" · fcbf94b9
      Linus Torvalds authored
      This reverts commit a32744d4
      
      .
      
      While that commit was technically the right thing to do, and made the
      x86-64 compat mode work identically to native 32-bit mode (and thus
      fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
      turns out that the automount binaries had workarounds for this compat
      problem.
      
      Now, the workarounds are disgusting: doing an "uname()" to find out the
      architecture of the kernel, and then comparing it for the 64-bit cases
      and fixing up the size of the read() in automount for those.  And they
      were confused: it's not actually a generic 64-bit issue at all, it's
      very much tied to just x86-64, which has different alignment for an
      'u64' in 64-bit mode than in 32-bit mode.
      
      But the end result is that fixing the compat layer actually breaks the
      case of a 32-bit automount on a x86-64 kernel.
      
      There are various approaches to fix this (including just doing a
      "strcmp()" on current->comm and comparing it to "automount"), but I
      think that I will do the one that teaches pipes about a special "packet
      mode", which will allow user space to not have to care too deeply about
      the padding at the end of the autofs packet.
      
      That change will make the compat workaround unnecessary, so let's revert
      it first, and get automount working again in compat mode.  The
      packetized pipes will then fix autofs for systemd.
      Reported-and-requested-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Cc: Ian Kent <raven@themaw.net>
      Cc: stable@kernel.org # for 3.3
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fcbf94b9
  2. 25 Feb, 2012 1 commit
    • Ian Kent's avatar
      autofs: work around unhappy compat problem on x86-64 · a32744d4
      Ian Kent authored
      When the autofs protocol version 5 packet type was added in commit
      5c0a32fc
      
       ("autofs4: add new packet type for v5 communications"), it
      obvously tried quite hard to be word-size agnostic, and uses explicitly
      sized fields that are all correctly aligned.
      
      However, with the final "char name[NAME_MAX+1]" array at the end, the
      actual size of the structure ends up being not very well defined:
      because the struct isn't marked 'packed', doing a "sizeof()" on it will
      align the size of the struct up to the biggest alignment of the members
      it has.
      
      And despite all the members being the same, the alignment of them is
      different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
      alignment on x86-64.  And while 'NAME_MAX+1' ends up being a nice round
      number (256), the name[] array starts out a 4-byte aligned.
      
      End result: the "packed" size of the structure is 300 bytes: 4-byte, but
      not 8-byte aligned.
      
      As a result, despite all the fields being in the same place on all
      architectures, sizeof() will round up that size to 304 bytes on
      architectures that have 8-byte alignment for u64.
      
      Note that this is *not* a problem for 32-bit compat mode on POWER, since
      there __u64 is 8-byte aligned even in 32-bit mode.  But on x86, 32-bit
      and 64-bit alignment is different for 64-bit entities, and as a result
      the structure that has exactly the same layout has different sizes.
      
      So on x86-64, but no other architecture, we will just subtract 4 from
      the size of the structure when running in a compat task.  That way we
      will write the properly sized packet that user mode expects.
      
      Not pretty.  Sadly, this very subtle, and unnecessary, size difference
      has been encoded in user space that wants to read packets of *exactly*
      the right size, and will refuse to touch anything else.
      Reported-and-tested-by: default avatarThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a32744d4
  3. 10 Jan, 2012 1 commit
  4. 03 Jan, 2012 1 commit
  5. 08 Aug, 2011 1 commit
  6. 24 Mar, 2011 1 commit
  7. 17 Jan, 2011 6 commits
  8. 15 Jan, 2011 7 commits
    • David Howells's avatar
      autofs4: Merge the remaining dentry ops tables · b650c858
      David Howells authored
      
      
      Merge the remaining autofs4 dentry ops tables.  It doesn't matter if
      d_automount and d_manage are present on something that's not mountable or
      holdable as these ops are only used if the appropriate flags are set in
      dentry->d_flags.
      
      [AV] switch to ->s_d_op, since now _everything_ on autofs4 is using the
      same dentry_operations.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b650c858
    • Ian Kent's avatar
      autofs4: Clean up dentry operations · 71e469db
      Ian Kent authored
      
      
      There are now two distinct dentry operations uses. One for dentrys
      that trigger mounts and one for dentrys that do not.
      
      Rationalize the use of these dentry operations and rename them to
      reflect their function.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      71e469db
    • Ian Kent's avatar
      autofs4: Clean up inode operations · e61da20a
      Ian Kent authored
      
      
      Since the use of ->follow_link() has been eliminated there is no
      need to separate the indirect and direct inode operations.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      e61da20a
    • Ian Kent's avatar
      autofs4: Remove unused code · 8c13a676
      Ian Kent authored
      
      
      Remove code that is not used due to the use of ->d_automount()
      and ->d_manage().
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      8c13a676
    • Ian Kent's avatar
      autofs4: Add d_manage() dentry operation · b5b80177
      Ian Kent authored
      
      
      This patch required a previous patch to add the ->d_automount()
      dentry operation.
      
      Add a function to use the newly defined ->d_manage() dentry operation
      for blocking during mount and expire.
      
      Whether the VFS calls the dentry operations d_automount() and d_manage()
      is controled by the DMANAGED_AUTOMOUNT and DMANAGED_TRANSIT flags. autofs
      uses the d_automount() operation to callback to user space to request
      mount operations and the d_manage() operation to block walks into mounts
      that are under construction or destruction.
      
      In order to prevent these functions from being called unnecessarily the
      DMANAGED_* flags are cleared for cases which would cause this. In the
      common case the DMANAGED_AUTOMOUNT and DMANAGED_TRANSIT flags are both
      set for dentrys waiting to be mounted. The DMANAGED_TRANSIT flag is
      cleared upon successful mount request completion and set during expire
      runs, both during the dentry expire check, and if selected for expire,
      is left set until a subsequent successful mount request completes.
      
      The exception to this is the so-called rootless multi-mount which has
      no actual mount at its base. In this case the DMANAGED_AUTOMOUNT flag
      is cleared upon successful mount request completion as well and set
      again after a successful expire.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b5b80177
    • Ian Kent's avatar
      autofs4: Add d_automount() dentry operation · 10584211
      Ian Kent authored
      
      
      Add a function to use the newly defined ->d_automount() dentry operation
      for triggering mounts instead of doing the user space callback in ->lookup()
      and ->d_revalidate().
      
      Note, to be useful the subsequent patch to add the ->d_manage() dentry
      operation is also needed so the discussion of functionality is deferred to
      that patch.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      10584211
    • David Howells's avatar
      Add a dentry op to allow processes to be held during pathwalk transit · cc53ce53
      David Howells authored
      
      
      Add a dentry op (d_manage) to permit a filesystem to hold a process and make it
      sleep when it tries to transit away from one of that filesystem's directories
      during a pathwalk.  The operation is keyed off a new dentry flag
      (DCACHE_MANAGE_TRANSIT).
      
      The filesystem is allowed to be selective about which processes it holds and
      which it permits to continue on or prohibits from transiting from each flagged
      directory.  This will allow autofs to hold up client processes whilst letting
      its userspace daemon through to maintain the directory or the stuff behind it
      or mounted upon it.
      
      The ->d_manage() dentry operation:
      
      	int (*d_manage)(struct path *path, bool mounting_here);
      
      takes a pointer to the directory about to be transited away from and a flag
      indicating whether the transit is undertaken by do_add_mount() or
      do_move_mount() skipping through a pile of filesystems mounted on a mountpoint.
      
      It should return 0 if successful and to let the process continue on its way;
      -EISDIR to prohibit the caller from skipping to overmounted filesystems or
      automounting, and to use this directory; or some other error code to return to
      the user.
      
      ->d_manage() is called with namespace_sem writelocked if mounting_here is true
      and no other locks held, so it may sleep.  However, if mounting_here is true,
      it may not initiate or wait for a mount or unmount upon the parameter
      directory, even if the act is actually performed by userspace.
      
      Within fs/namei.c, follow_managed() is extended to check with d_manage() first
      on each managed directory, before transiting away from it or attempting to
      automount upon it.
      
      follow_down() is renamed follow_down_one() and should only be used where the
      filesystem deliberately intends to avoid management steps (e.g. autofs).
      
      A new follow_down() is added that incorporates the loop done by all other
      callers of follow_down() (do_add/move_mount(), autofs and NFSD; whilst AFS, NFS
      and CIFS do use it, their use is removed by converting them to use
      d_automount()).  The new follow_down() calls d_manage() as appropriate.  It
      also takes an extra parameter to indicate if it is being called from mount code
      (with namespace_sem writelocked) which it passes to d_manage().  follow_down()
      ignores automount points so that it can be used to mount on them.
      
      __follow_mount_rcu() is made to abort rcu-walk mode if it hits a directory with
      DCACHE_MANAGE_TRANSIT set on the basis that we're probably going to have to
      sleep.  It would be possible to enter d_manage() in rcu-walk mode too, and have
      that determine whether to abort or not itself.  That would allow the autofs
      daemon to continue on in rcu-walk mode.
      
      Note that DCACHE_MANAGE_TRANSIT on a directory should be cleared when it isn't
      required as every tranist from that directory will cause d_manage() to be
      invoked.  It can always be set again when necessary.
      
      ==========================
      WHAT THIS MEANS FOR AUTOFS
      ==========================
      
      Autofs currently uses the lookup() inode op and the d_revalidate() dentry op to
      trigger the automounting of indirect mounts, and both of these can be called
      with i_mutex held.
      
      autofs knows that the i_mutex will be held by the caller in lookup(), and so
      can drop it before invoking the daemon - but this isn't so for d_revalidate(),
      since the lock is only held on _some_ of the code paths that call it.  This
      means that autofs can't risk dropping i_mutex from its d_revalidate() function
      before it calls the daemon.
      
      The bug could manifest itself as, for example, a process that's trying to
      validate an automount dentry that gets made to wait because that dentry is
      expired and needs cleaning up:
      
      	mkdir         S ffffffff8014e05a     0 32580  24956
      	Call Trace:
      	 [<ffffffff885371fd>] :autofs4:autofs4_wait+0x674/0x897
      	 [<ffffffff80127f7d>] avc_has_perm+0x46/0x58
      	 [<ffffffff8009fdcf>] autoremove_wake_function+0x0/0x2e
      	 [<ffffffff88537be6>] :autofs4:autofs4_expire_wait+0x41/0x6b
      	 [<ffffffff88535cfc>] :autofs4:autofs4_revalidate+0x91/0x149
      	 [<ffffffff80036d96>] __lookup_hash+0xa0/0x12f
      	 [<ffffffff80057a2f>] lookup_create+0x46/0x80
      	 [<ffffffff800e6e31>] sys_mkdirat+0x56/0xe4
      
      versus the automount daemon which wants to remove that dentry, but can't
      because the normal process is holding the i_mutex lock:
      
      	automount     D ffffffff8014e05a     0 32581      1              32561
      	Call Trace:
      	 [<ffffffff80063c3f>] __mutex_lock_slowpath+0x60/0x9b
      	 [<ffffffff8000ccf1>] do_path_lookup+0x2ca/0x2f1
      	 [<ffffffff80063c89>] .text.lock.mutex+0xf/0x14
      	 [<ffffffff800e6d55>] do_rmdir+0x77/0xde
      	 [<ffffffff8005d229>] tracesys+0x71/0xe0
      	 [<ffffffff8005d28d>] tracesys+0xd5/0xe0
      
      which means that the system is deadlocked.
      
      This patch allows autofs to hold up normal processes whilst the daemon goes
      ahead and does things to the dentry tree behind the automouter point without
      risking a deadlock as almost no locks are held in d_manage() and none in
      d_automount().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Was-Acked-by: default avatarIan Kent <raven@themaw.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      cc53ce53
  9. 06 Jan, 2011 3 commits
    • Nick Piggin's avatar
      fs: dcache remove dcache_lock · b5c84bf6
      Nick Piggin authored
      
      
      dcache_lock no longer protects anything. remove it.
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      b5c84bf6
    • Nick Piggin's avatar
      fs: dcache scale subdirs · 2fd6b7f5
      Nick Piggin authored
      
      
      Protect d_subdirs and d_child with d_lock, except in filesystems that aren't
      using dcache_lock for these anyway (eg. using i_mutex).
      
      Note: if we change the locking rule in future so that ->d_child protection is
      provided only with ->d_parent->d_lock, it may allow us to reduce some locking.
      But it would be an exception to an otherwise regular locking scheme, so we'd
      have to see some good results. Probably not worthwhile.
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      2fd6b7f5
    • Nick Piggin's avatar
      fs: dcache scale d_unhashed · da502956
      Nick Piggin authored
      
      
      Protect d_unhashed(dentry) condition with d_lock. This means keeping
      DCACHE_UNHASHED bit in synch with hash manipulations.
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      da502956
  10. 03 Mar, 2010 1 commit
  11. 16 Dec, 2009 4 commits
  12. 11 Jun, 2009 1 commit
  13. 01 Apr, 2009 1 commit
  14. 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
  15. 16 Oct, 2008 3 commits
  16. 24 Jul, 2008 7 commits
    • Ian Kent's avatar
      autofs4: reorganize expire pending wait function calls · 06a35985
      Ian Kent authored
      
      
      This patch re-orgnirzes the checking for and waiting on active expires and
      elininates redundant checks.
      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>
      06a35985
    • Ian Kent's avatar
      autofs4: fix direct mount pending expire race · 6e60a9ab
      Ian Kent authored
      
      
      For direct and offset type mounts that are covered by another mount we
      cannot check the AUTOFS_INF_EXPIRING flag during a path walk which leads
      to lookups walking into an expiring mount while it is being expired.
      
      For example, for the direct multi-mount map entry with a couple of
      offsets:
      
      /race/mm1  /      <server1>:/<path1>
                 /om1   <server2>:/<path2>
                 /om2   <server1>:/<path3>
      
      an autofs trigger mount is mounted on /race/mm1 and when accessed it is
      over mounted and trigger mounts made for /race/mm1/om1 and /race/mm1/om2.
      So it isn't possible for path walks to see the expiring flag at all and
      they happily walk into the file system while it is expiring.
      
      When expiring these mounts follow_down() must stop at the autofs mount and
      all processes must block in the ->follow_link() method (except the daemon)
      until the expire is complete.  This is done by decrementing the d_mounted
      field of the autofs trigger mount root dentry until the expire is
      completed.  In ->follow_link() all processes wait on the expire and the
      mount following is completed for the daemon until the expire is complete.
      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>
      6e60a9ab
    • Ian Kent's avatar
      autofs4: fix indirect mount pending expire race · 97e7449a
      Ian Kent authored
      
      
      The selection of a dentry for expiration and the setting of the
      AUTOFS_INF_EXPIRING flag isn't done atomically which can lead to lookups
      walking into an expiring mount.
      
      What happens is that an expire is initiated by the daemon and a dentry is
      selected for expire but, since there is no lock held between the selection
      and setting of the expiring flag, a process may find the flag clear and
      continue walking into the mount tree at the same time the daemon attempts
      the expire it.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Reviewed-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>
      97e7449a
    • 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
    • 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
    • Ian Kent's avatar
      autofs4: use look aside list for lookups · 25767378
      Ian Kent authored
      
      
      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: 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>
      25767378
    • Ian Kent's avatar
      autofs4: don't make expiring dentry negative · 5f6f4f28
      Ian Kent authored
      
      
      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: 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>
      5f6f4f28