1. 22 Aug, 2018 1 commit
  2. 08 Jun, 2018 4 commits
  3. 09 Sep, 2017 1 commit
  4. 10 Jul, 2017 1 commit
    • Linus Torvalds's avatar
      Fix up over-eager 'wait_queue_t' renaming · 7cee9384
      Linus Torvalds authored
      Commit ac6424b9 ("sched/wait: Rename wait_queue_t =>
      wait_queue_entry_t") had scripted the renaming incorrectly, and didn't
      actually check that the 'wait_queue_t' was a full token.
      As a result, it also triggered on 'wait_queue_token', and renamed that
      to 'wait_queue_entry_token' entry in the autofs4 packet structure
      definition too.  That was entirely incorrect, and not intended.
      The end result built fine when building just the kernel - because
      everything had been renamed consistently there - but caused problems in
      user space because the "struct autofs_packet_missing" type is exported
      as part of the uapi.
      This scripts it all back again:
          git grep -lw wait_queue_entry_token |
              xargs sed -i 's/wait_queue_entry_token/wait_queue_token/g'
      and checks the end result.
      Reported-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Fixes: ac6424b9 ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 20 Jun, 2017 1 commit
    • Ingo Molnar's avatar
      sched/wait: Rename wait_queue_t => wait_queue_entry_t · ac6424b9
      Ingo Molnar authored
      	wait_queue_t		=>	wait_queue_entry_t
      'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue",
      but in reality it's a queue *entry*. The 'real' queue is the wait queue head,
      which had to carry the name.
      Start sorting this out by renaming it to 'wait_queue_entry_t'.
      This also allows the real structure name 'struct __wait_queue' to
      lose its double underscore and become 'struct wait_queue_entry',
      which is the more canonical nomenclature for such data types.
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  6. 02 Mar, 2017 1 commit
    • Ingo Molnar's avatar
      rcu: Separate the RCU synchronization types and APIs into <linux/rcupdate_wait.h> · f9411ebe
      Ingo Molnar authored
      So rcupdate.h is a pretty complex header, in particular it includes
      <linux/completion.h> which includes <linux/wait.h> - creating a
      dependency that includes <linux/wait.h> in <linux/sched.h>,
      which prevents the isolation of <linux/sched.h> from the derived
      <linux/wait.h> header.
      Solve part of the problem by decoupling rcupdate.h from completions:
      this can be done by separating out the rcu_synchronize types and APIs,
      and updating their usage sites.
      Since this is a mostly RCU-internal types this will not just simplify
      <linux/sched.h>'s dependencies, but will make all the hundreds of
      .c files that include rcupdate.h but not completions or wait.h build
      ( For rcutiny this means that two dependent APIs have to be uninlined,
        but that shouldn't be much of a problem as they are rare variants. )
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  7. 04 Dec, 2016 2 commits
  8. 11 Oct, 2016 4 commits
  9. 12 Jun, 2016 1 commit
    • Al Viro's avatar
      autofs races · ea01a184
      Al Viro authored
      * make autofs4_expire_indirect() skip the dentries being in process of
      * do *not* mess with list_move(); making sure that dentry with
      AUTOFS_INF_EXPIRING are not picked for expiry is enough.
      * do not remove NO_RCU when we set EXPIRING, don't bother with smp_mb()
      there.  Clear it at the same time we clear EXPIRING.  Makes a bunch of
      tests simpler.
      * rename NO_RCU to WANT_EXPIRE, which is what it really is.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  10. 15 Mar, 2016 4 commits
  11. 23 Jun, 2015 1 commit
  12. 15 Apr, 2015 1 commit
  13. 12 Apr, 2015 1 commit
  14. 14 Oct, 2014 2 commits
    • NeilBrown's avatar
      autofs4: avoid taking fs_lock during rcu-walk · 4d885f90
      NeilBrown authored
      ->fs_lock protects AUTOFS_INF_EXPIRING.  We need to be sure that once
      the flag is set, no new references beneath the dentry are taken.  So
      rcu-walk currently needs to take fs_lock before checking the flag.  This
      hurts performance.
      Change the expiry to a two-stage process.  First set AUTOFS_INF_NO_RCU
      which forces any path walk into ref-walk mode, then drop the lock and
      call synchronize_rcu().  Once that returns we can be sure no rcu-walk is
      active beneath the dentry and we can check reference counts again.
      Now during an RCU-walk we can test AUTOFS_INF_EXPIRING without taking
      the lock as along as we test AUTOFS_INF_NO_RCU too.  If either are set,
      we must abort the RCU-walk If neither are set, we know that refcounts
      will be tested again after we finish the RCU-walk so we are safe to
      ->fs_lock is still taken in d_manage() to check for a non-trap
      directory.  That will be resolved in the next patch.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reviewed-by: default avatarIan Kent <raven@themaw.net>
      Tested-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>
    • NeilBrown's avatar
      autofs4: allow RCU-walk to walk through autofs4 · 23bfc2a2
      NeilBrown authored
      This series teaches autofs about RCU-walk so that we don't drop straight
      into REF-walk when we hit an autofs directory, and so that we avoid
      spinlocks as much as possible when performing an RCU-walk.
      This is needed so that the benefits of the recent NFS support for
      RCU-walk are fully available when NFS filesystems are automounted.
      Patches have been carefully reviewed and tested both with test suites
      and in production - thanks a lot to Ian Kent for his support there.
      This patch (of 6):
      Any attempt to look up a pathname that passes though an autofs4 mount is
      currently forced out of RCU-walk into REF-walk.
      This can significantly hurt performance of many-thread work loads on
      many-core systems, especially if the automounted filesystem supports
      RCU-walk but doesn't get to benefit from it.
      So if autofs4_d_manage is called with rcu_walk set, only fail with -ECHILD
      if it is necessary to wait longer than a spinlock.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reviewed-by: default avatarIan Kent <raven@themaw.net>
      Tested-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>
  15. 08 Aug, 2014 2 commits
  16. 24 Jan, 2014 1 commit
    • Sukadev Bhattiprolu's avatar
      autofs4: allow autofs to work outside the initial PID namespace · 6eaba35b
      Sukadev Bhattiprolu authored
      Enable autofs4 to work in a "container".  oz_pgrp is converted from
      pid_t to struct pid and this is stored at mount time based on the
      "pgrp=" option or if the option is missing then the current pgrp.
      The "pgrp=" option is interpreted in the PID namespace of the current
      process.  This option is flawed in that it doesn't carry the namespace
      information, so it should be deprecated.  AFAICS the autofs daemon
      always sends the current pgrp, which is the default anyway.
      The oz_pgrp is also set from the AUTOFS_DEV_IOCTL_SETPIPEFD_CMD ioctl.
      This ioctl sets oz_pgrp to the current pgrp.  It is not allowed to
      change the pid namespace.
      oz_pgrp is used mainly to determine whether the process traversing the
      autofs mount tree is the autofs daemon itself or not.  This function now
      compares the pid pointers instead of the pid_t values.
      One other use of oz_pgrp is in autofs4_show_options.  There is shows the
      virtual pid number (i.e.  the one that is valid inside the PID namespace
      of the calling process)
      For debugging printk convert oz_pgrp to the value in the initial pid
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Acked-by: default avatarIan Kent <raven@themaw.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 25 Oct, 2013 2 commits
  18. 23 Feb, 2013 1 commit
  19. 15 Nov, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Support autofs4 interacing with multiple user namespaces · 45634cd8
      Eric W. Biederman authored
      Use kuid_t and kgid_t in struct autofs_info and struct autofs_wait_queue.
      When creating directories and symlinks default the uid and gid of
      the mount requester to the global root uid and gid.  autofs4_wait
      will update these fields when a mount is requested.
      When generating autofsv5 packets report the uid and gid of the mount
      requestor in user namespace of the process that opened the pipe,
      reporting unmapped uids and gids as overflowuid and overflowgid.
      In autofs_dev_ioctl_requester return the uid and gid of the last mount
      requester converted into the calling processes user namespace.  When the
      uid or gid don't map return overflowuid and overflowgid as appropriate,
      allowing failure to find a mount requester to be distinguished from
      failure to map a mount requester.
      The uid and gid mount options specifying the user and group of the
      root autofs inode are converted into kuid and kgid as they are parsed
      defaulting to the current uid and current gid of the process that
      mounts autofs.
      Mounting of autofs for the present remains confined to processes in
      the initial user namespace.
      Cc: Ian Kent <raven@themaw.net>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
  20. 29 Apr, 2012 1 commit
    • Linus Torvalds's avatar
      autofs: make the autofsv5 packet file descriptor use a packetized pipe · 64f371bc
      Linus Torvalds authored
      The autofs packet size has had a very unfortunate size problem on x86:
      because the alignment of 'u64' differs in 32-bit and 64-bit modes, and
      because the packet data was not 8-byte aligned, the size of the autofsv5
      packet structure differed between 32-bit and 64-bit modes despite
      looking otherwise identical (300 vs 304 bytes respectively).
      We first fixed that up by making the 64-bit compat mode know about this
      problem in commit a32744d4 ("autofs: work around unhappy compat
      problem on x86-64"), and that made a 32-bit 'systemd' work happily on a
      64-bit kernel because everything then worked the same way as on a 32-bit
      But it turned out that 'automount' had actually known and worked around
      this problem in user space, so fixing the kernel to do the proper 32-bit
      compatibility handling actually *broke* 32-bit automount on a 64-bit
      kernel, because it knew that the packet sizes were wrong and expected
      those incorrect sizes.
      As a result, we ended up reverting that compatibility mode fix, and
      thus breaking systemd again, in commit fcbf94b9.
      With both automount and systemd doing a single read() system call, and
      verifying that they get *exactly* the size they expect but using
      different sizes, it seemed that fixing one of them inevitably seemed to
      break the other.  At one point, a patch I seriously considered applying
      from Michael Tokarev did a "strcmp()" to see if it was automount that
      was doing the operation.  Ugly, ugly.
      However, a prettier solution exists now thanks to the packetized pipe
      mode.  By marking the communication pipe as being packetized (by simply
      setting the O_DIRECT flag), we can always just write the bigger packet
      size, and if user-space does a smaller read, it will just get that
      partial end result and the extra alignment padding will simply be thrown
      This makes both automount and systemd happy, since they now get the size
      they asked for, and the kernel side of autofs simply no longer needs to
      care - it could pad out the packet arbitrarily.
      Of course, if there is some *other* user of autofs (please, please,
      please tell me it ain't so - and we haven't heard of any) that tries to
      read the packets with multiple writes, that other user will now be
      broken - the whole point of the packetized mode is that one system call
      gets exactly one packet, and you cannot read a packet in pieces.
      Tested-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Thomas Meyer <thomas@m3y3r.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  21. 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
      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>
  22. 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>
  23. 11 Jan, 2012 1 commit
  24. 04 Jan, 2012 1 commit
  25. 08 Aug, 2011 1 commit
  26. 24 Mar, 2011 1 commit
  27. 18 Jan, 2011 1 commit