1. 22 Oct, 2015 34 commits
  2. 01 Oct, 2015 6 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.90 · f5552cd8
      Greg Kroah-Hartman authored
      f5552cd8
    • Markus Pargmann's avatar
      Revert "iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required" · d565d87e
      Markus Pargmann authored
      This reverts commit 35c45e8b which was
      commit 06d2f6ca upstream as it should
      not have been applied.
      Reported-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Cc: Markus Pargmann <mpa@pengutronix.de>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d565d87e
    • Eric W. Biederman's avatar
      vfs: Remove incorrect debugging WARN in prepend_path · e6478de4
      Eric W. Biederman authored
      commit 93e3bce6 upstream.
      
      The warning message in prepend_path is unclear and outdated.  It was
      added as a warning that the mechanism for generating names of pseudo
      files had been removed from prepend_path and d_dname should be used
      instead.  Unfortunately the warning reads like a general warning,
      making it unclear what to do with it.
      
      Remove the warning.  The transition it was added to warn about is long
      over, and I added code several years ago which in rare cases causes
      the warning to fire on legitimate code, and the warning is now firing
      and scaring people for no good reason.
      Reported-by: default avatarIvan Delalande <colona@arista.com>
      Reported-by: default avatarOmar Sandoval <osandov@osandov.com>
      Fixes: f48cfddc ("vfs: In d_path don't call d_dname on a mount point")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      [ vlee: Backported to 3.10. Adjusted context. ]
      Signed-off-by: default avatarVinson Lee <vlee@twitter.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6478de4
    • Wilson Kok's avatar
      fib_rules: fix fib rule dumps across multiple skbs · d0550a3f
      Wilson Kok authored
      [ Upstream commit 41fc0143 ]
      
      dump_rules returns skb length and not error.
      But when family == AF_UNSPEC, the caller of dump_rules
      assumes that it returns an error. Hence, when family == AF_UNSPEC,
      we continue trying to dump on -EMSGSIZE errors resulting in
      incorrect dump idx carried between skbs belonging to the same dump.
      This results in fib rule dump always only dumping rules that fit
      into the first skb.
      
      This patch fixes dump_rules to return error so that we exit correctly
      and idx is correctly maintained between skbs that are part of the
      same dump.
      Signed-off-by: default avatarWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0550a3f
    • Marcelo Ricardo Leitner's avatar
      sctp: fix race on protocol/netns initialization · e7bb902b
      Marcelo Ricardo Leitner authored
      [ Upstream commit 8e2d61e0 ]
      
      Consider sctp module is unloaded and is being requested because an user
      is creating a sctp socket.
      
      During initialization, sctp will add the new protocol type and then
      initialize pernet subsys:
      
              status = sctp_v4_protosw_init();
              if (status)
                      goto err_protosw_init;
      
              status = sctp_v6_protosw_init();
              if (status)
                      goto err_v6_protosw_init;
      
              status = register_pernet_subsys(&sctp_net_ops);
      
      The problem is that after those calls to sctp_v{4,6}_protosw_init(), it
      is possible for userspace to create SCTP sockets like if the module is
      already fully loaded. If that happens, one of the possible effects is
      that we will have readers for net->sctp.local_addr_list list earlier
      than expected and sctp_net_init() does not take precautions while
      dealing with that list, leading to a potential panic but not limited to
      that, as sctp_sock_init() will copy a bunch of blank/partially
      initialized values from net->sctp.
      
      The race happens like this:
      
           CPU 0                           |  CPU 1
        socket()                           |
         __sock_create                     | socket()
          inet_create                      |  __sock_create
           list_for_each_entry_rcu(        |
              answer, &inetsw[sock->type], |
              list) {                      |   inet_create
            /* no hits */                  |
           if (unlikely(err)) {            |
            ...                            |
            request_module()               |
            /* socket creation is blocked  |
             * the module is fully loaded  |
             */                            |
             sctp_init                     |
              sctp_v4_protosw_init         |
               inet_register_protosw       |
                list_add_rcu(&p->list,     |
                             last_perm);   |
                                           |  list_for_each_entry_rcu(
                                           |     answer, &inetsw[sock->type],
              sctp_v6_protosw_init         |     list) {
                                           |     /* hit, so assumes protocol
                                           |      * is already loaded
                                           |      */
                                           |  /* socket creation continues
                                           |   * before netns is initialized
                                           |   */
              register_pernet_subsys       |
      
      Simply inverting the initialization order between
      register_pernet_subsys() and sctp_v4_protosw_init() is not possible
      because register_pernet_subsys() will create a control sctp socket, so
      the protocol must be already visible by then. Deferring the socket
      creation to a work-queue is not good specially because we loose the
      ability to handle its errors.
      
      So, as suggested by Vlad, the fix is to split netns initialization in
      two moments: defaults and control socket, so that the defaults are
      already loaded by when we register the protocol, while control socket
      initialization is kept at the same moment it is today.
      
      Fixes: 4db67e80 ("sctp: Make the address lists per network namespace")
      Signed-off-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7bb902b
    • Richard Laing's avatar
      net/ipv6: Correct PIM6 mrt_lock handling · 02b5ca77
      Richard Laing authored
      [ Upstream commit 25b4a44c ]
      
      In the IPv6 multicast routing code the mrt_lock was not being released
      correctly in the MFC iterator, as a result adding or deleting a MIF would
      cause a hang because the mrt_lock could not be acquired.
      
      This fix is a copy of the code for the IPv4 case and ensures that the lock
      is released correctly.
      Signed-off-by: default avatarRichard Laing <richard.laing@alliedtelesis.co.nz>
      Acked-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02b5ca77