1. 31 May, 2014 40 commits
    • Duan Jiong's avatar
      neigh: set nud_state to NUD_INCOMPLETE when probing router reachability · c712c1f7
      Duan Jiong authored
      [ Upstream commit 2176d5d4 ]
      
      Since commit 7e980569("ipv6: router reachability probing"), a router falls
      into NUD_FAILED will be probed.
      
      Now if function rt6_select() selects a router which neighbour state is NUD_FAILED,
      and at the same time function rt6_probe() changes the neighbour state to NUD_PROBE,
      then function dst_neigh_output() can directly send packets, but actually the
      neighbour still is unreachable. If we set nud_state to NUD_INCOMPLETE instead
      NUD_PROBE, packets will not be sent out until the neihbour is reachable.
      
      In addition, because the route should be probes with a single NS, so we must
      set neigh->probes to neigh_max_probes(), then the neigh timer timeout and function
      neigh_timer_handler() will not send other NS Messages.
      Signed-off-by: default avatarDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c712c1f7
    • Susant Sahani's avatar
      ip6_tunnel: fix potential NULL pointer dereference · a3db451d
      Susant Sahani authored
      [ Upstream commit c8965932 ]
      
      The function ip6_tnl_validate assumes that the rtnl
      attribute IFLA_IPTUN_PROTO always be filled . If this
      attribute is not filled by  the userspace application
      kernel get crashed with NULL pointer dereference. This
      patch fixes the potential kernel crash when
      IFLA_IPTUN_PROTO is missing .
      Signed-off-by: default avatarSusant Sahani <susant@redhat.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3db451d
    • Nikolay Aleksandrov's avatar
      sfc: fix calling of free_irq with already free vector · e31895fa
      Nikolay Aleksandrov authored
      [ Upstream commit 1c363900 ]
      
      If the sfc driver is in legacy interrupt mode (either explicitly by
      using interrupt_mode module param or by falling back to it) it will
      hit a warning at kernel/irq/manage.c because it will try to free an irq
      which wasn't allocated by it in the first place because the MSI(X) irqs are
      zero and it'll try to free them unconditionally. So fix it by checking if
      we're in legacy mode and freeing the appropriate irqs.
      
      CC: Zenghui Shi <zshi@redhat.com>
      CC: Ben Hutchings <ben@decadent.org.uk>
      CC: <linux-net-drivers@solarflare.com>
      CC: Shradha Shah <sshah@solarflare.com>
      CC: David S. Miller <davem@davemloft.net>
      
      Fixes: 1899c111 ("sfc: Fix IRQ cleanup in case of a probe failure")
      Reported-by: default avatarZenghui Shi <zshi@redhat.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: default avatarShradha Shah <sshah@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e31895fa
    • Peter Christensen's avatar
      macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces. · 06465130
      Peter Christensen authored
      [ Upstream commit bbeb0ead ]
      
      Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
      overflow on the underlying interface.
      
      Attempting the set IFF_ALLMULTI on the underlying interface would cause an
      error and the log message:
      
      "allmulti touches root, set allmulti failed."
      Signed-off-by: default avatarPeter Christensen <pch@ordbogen.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06465130
    • Bjørn Mork's avatar
      net: cdc_mbim: handle unaccelerated VLAN tagged frames · d177ade5
      Bjørn Mork authored
      [ Upstream commit 6b5eeb7f ]
      
      This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on
      a bogus assumption that all tagged frames will use the acceleration API
      because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames
      tagged in userspace using packet sockets. Such frames will erroneously
      be considered as untagged and silently dropped based on not being IP.
      
      Fix by falling back to looking into the ethernet header for a tag if no
      accelerated tag was found.
      
      Fixes: a82c7ce5 ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID")
      Cc: Greg Suarez <gsuarez@smithmicro.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d177ade5
    • Sergey Popovich's avatar
      ipv4: fib_semantics: increment fib_info_cnt after fib_info allocation · 13c5c91b
      Sergey Popovich authored
      [ Upstream commit aeefa1ec ]
      
      Increment fib_info_cnt in fib_create_info() right after successfuly
      alllocating fib_info structure, overwise fib_metrics allocation failure
      leads to fib_info_cnt incorrectly decremented in free_fib_info(), called
      on error path from fib_create_info().
      Signed-off-by: default avatarSergey Popovich <popovich_sergei@mail.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13c5c91b
    • Florian Westphal's avatar
      net: ipv6: send pkttoobig immediately if orig frag size > mtu · 8eb6ded7
      Florian Westphal authored
      [ Upstream commit 418a3156 ]
      
      If conntrack defragments incoming ipv6 frags it stores largest original
      frag size in ip6cb and sets ->local_df.
      
      We must thus first test the largest original frag size vs. mtu, and not
      vice versa.
      
      Without this patch PKTTOOBIG is still generated in ip6_fragment() later
      in the stack, but
      
      1) IPSTATS_MIB_INTOOBIGERRORS won't increment
      2) packet did (needlessly) traverse netfilter postrouting hook.
      
      Fixes: fe6cc55f ("net: ip, ipv6: handle gso skbs in forwarding path")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8eb6ded7
    • Florian Westphal's avatar
      net: ipv4: ip_forward: fix inverted local_df test · 1f68835d
      Florian Westphal authored
      [ Upstream commit ca6c5d4a ]
      
      local_df means 'ignore DF bit if set', so if its set we're
      allowed to perform ip fragmentation.
      
      This wasn't noticed earlier because the output path also drops such skbs
      (and emits needed icmp error) and because netfilter ip defrag did not
      set local_df until couple of days ago.
      
      Only difference is that DF-packets-larger-than MTU now discarded
      earlier (f.e. we avoid pointless netfilter postrouting trip).
      
      While at it, drop the repeated test ip_exceeds_mtu, checking it once
      is enough...
      
      Fixes: fe6cc55f ("net: ip, ipv6: handle gso skbs in forwarding path")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f68835d
    • Bjørn Mork's avatar
      net: cdc_mbim: __vlan_find_dev_deep need rcu_read_lock · b8313dbb
      Bjørn Mork authored
      [ Upstream commit 4f4178f3 ]
      
      Fixes this warning introduced by commit 5b8f15f7
      ("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      3.15.0-rc3 #213 Tainted: G        W  O
      -------------------------------
      net/8021q/vlan_core.c:69 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 1
      no locks held by ksoftirqd/0/3.
      
      stack backtrace:
      CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G        W  O  3.15.0-rc3 #213
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       0000000000000001 ffff880232533bf0 ffffffff813a5ee6 0000000000000006
       ffff880232530090 ffff880232533c20 ffffffff81076b94 0000000000000081
       0000000000000000 ffff8802085ac000 ffff88007fc8ea00 ffff880232533c50
      Call Trace:
       [<ffffffff813a5ee6>] dump_stack+0x4e/0x68
       [<ffffffff81076b94>] lockdep_rcu_suspicious+0xfa/0x103
       [<ffffffff813978a6>] __vlan_find_dev_deep+0x54/0x94
       [<ffffffffa04a1938>] cdc_mbim_rx_fixup+0x379/0x66a [cdc_mbim]
       [<ffffffff813ab76f>] ? _raw_spin_unlock_irqrestore+0x3a/0x49
       [<ffffffff81079671>] ? trace_hardirqs_on_caller+0x192/0x1a1
       [<ffffffffa059bd10>] usbnet_bh+0x59/0x287 [usbnet]
       [<ffffffff8104067d>] tasklet_action+0xbb/0xcd
       [<ffffffff81040057>] __do_softirq+0x14c/0x30d
       [<ffffffff81040237>] run_ksoftirqd+0x1f/0x50
       [<ffffffff8105f13e>] smpboot_thread_fn+0x172/0x18e
       [<ffffffff8105efcc>] ? SyS_setgroups+0xdf/0xdf
       [<ffffffff810594b0>] kthread+0xb5/0xbd
       [<ffffffff813a84b1>] ? __wait_for_common+0x13b/0x170
       [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c
       [<ffffffff813b147c>] ret_from_fork+0x7c/0xb0
       [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c
      
      Fixes: 5b8f15f7 ("net: cdc_mbim: handle IPv6 Neigbor Solicitations")
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8313dbb
    • Timo Teräs's avatar
      ipv4: ip_tunnels: disable cache for nbma gre tunnels · 0bee206a
      Timo Teräs authored
      [ Upstream commit 22fb22ea ]
      
      The connected check fails to check for ip_gre nbma mode tunnels
      properly. ip_gre creates temporary tnl_params with daddr specified
      to pass-in the actual target on per-packet basis from neighbor
      layer. Detect these tunnels by inspecting the actual tunnel
      configuration.
      
      Minimal test case:
       ip route add 192.168.1.1/32 via 10.0.0.1
       ip route add 192.168.1.2/32 via 10.0.0.2
       ip tunnel add nbma0 mode gre key 1 tos c0
       ip addr add 172.17.0.0/16 dev nbma0
       ip link set nbma0 up
       ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
       ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
       ping 172.17.0.1
       ping 172.17.0.2
      
      The second ping should be going to 192.168.1.2 and head 10.0.0.2;
      but cached gre tunnel level route is used and it's actually going
      to 192.168.1.1 via 10.0.0.1.
      
      The lladdr's need to go to separate dst for the bug to trigger.
      Test case uses separate route entries, but this can also happen
      when the route entry is same: if there is a nexthop exception or
      the GRE tunnel is IPsec'ed in which case the dst points to xfrm
      bundle unique to the gre lladdr.
      
      Fixes: 7d442fab ("ipv4: Cache dst in tunnels")
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bee206a
    • Ying Cai's avatar
      ip_tunnel: Set network header properly for IP_ECN_decapsulate() · 22b2efbb
      Ying Cai authored
      [ Upstream commit e96f2e7c ]
      
      In ip_tunnel_rcv(), set skb->network_header to inner IP header
      before IP_ECN_decapsulate().
      
      Without the fix, IP_ECN_decapsulate() takes outer IP header as
      inner IP header, possibly causing error messages or packet drops.
      
      Note that this skb_reset_network_header() call was in this spot when
      the original feature for checking consistency of ECN bits through
      tunnels was added in eccc1bb8 ("tunnel: drop packet if ECN present
      with not-ECT"). It was only removed from this spot in 3d7b46cd
      ("ip_tunnel: push generic protocol handling to ip_tunnel module.").
      
      Fixes: 3d7b46cd ("ip_tunnel: push generic protocol handling to ip_tunnel module.")
      Reported-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYing Cai <ycai@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22b2efbb
    • Eyal Perry's avatar
      net/mlx4_core: Don't issue PCIe speed/width checks for VFs · 935ec25d
      Eyal Perry authored
      [ Upstream commit 83d3459a ]
      
      Carrying out PCI speed/width checks through pcie_get_minimum_link()
      on VFs yield wrong results, so remove them.
      
      Fixes: b912b2f8 ('net/mlx4_core: Warn if device doesn't have enough PCI bandwidth')
      Signed-off-by: default avatarEyal Perry <eyalpe@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      935ec25d
    • Bjørn Mork's avatar
      net: cdc_ncm: fix buffer overflow · 19ca28c3
      Bjørn Mork authored
      [ Upstream commit 9becd707 ]
      
      Commit 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs
      if we send ZLPs") changed the padding logic for devices with the ZLP
      flag set.  This meant that frames of any size will be sent without
      additional padding, except for the single byte added if the size is
      a multiple of the USB packet size. But if the unpadded size is
      identical to the maximum frame size, and the maximum size is a
      multiplum of the USB packet size, then this one-byte padding will
      overflow the buffer.
      
      Prevent padding if already at maximum frame size, letting usbnet
      transmit a ZLP instead in this case.
      
      Fixes: 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs")
      Reported by: Yu-an Shih <yshih@nvidia.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19ca28c3
    • Andy King's avatar
      vsock: Make transport the proto owner · 1b3ac848
      Andy King authored
      [ Upstream commit 2c4a336e ]
      
      Right now the core vsock module is the owner of the proto family. This
      means there's nothing preventing the transport module from unloading if
      there are open sockets, which results in a panic. Fix that by allowing
      the transport to be the owner, which will refcount it properly.
      
      Includes version bump to 1.0.1.0-k
      
      Passes checkpatch this time, I swear...
      Acked-by: default avatarDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: default avatarAndy King <acking@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b3ac848
    • John Fastabend's avatar
      net: sched: lock imbalance in hhf qdisc · ab7ba767
      John Fastabend authored
      [ Upstream commit f6a082fe ]
      
      hhf_change() takes the sch_tree_lock and releases it but misses the
      error cases. Fix the missed case here.
      
      To reproduce try a command like this,
      
      # tc qdisc change dev p3p2 root hhf quantum 40960 non_hh_weight 300000
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab7ba767
    • Liu Yu's avatar
      tcp_cubic: fix the range of delayed_ack · b2bb9ffd
      Liu Yu authored
      [ Upstream commit 0cda345d ]
      
      commit b9f47a3a (tcp_cubic: limit delayed_ack ratio to prevent
      divide error) try to prevent divide error, but there is still a little
      chance that delayed_ack can reach zero. In case the param cnt get
      negative value, then ratio+cnt would overflow and may happen to be zero.
      As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero.
      
      In some old kernels, such as 2.6.32, there is a bug that would
      pass negative param, which then ultimately leads to this divide error.
      
      commit 5b35e1e6 (tcp: fix tcp_trim_head() to adjust segment count
      with skb MSS) fixed the negative param issue. However,
      it's safe that we fix the range of delayed_ack as well,
      to make sure we do not hit a divide by zero.
      
      CC: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarLiu Yu <allanyuliu@tencent.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2bb9ffd
    • Vlad Yasevich's avatar
      Revert "macvlan : fix checksums error when we are in bridge mode" · cea2f34c
      Vlad Yasevich authored
      [ Upstream commit f114890c ]
      
      This reverts commit 12a2856b.
      The commit above doesn't appear to be necessary any more as the
      checksums appear to be correctly computed/validated.
      
      Additionally the above commit breaks kvm configurations where
      one VM is using a device that support checksum offload (virtio) and
      the other VM does not.
      In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
      set.  The packets is forwarded to a macvtap that has offload features
      turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
      update the checksum and thus a bad checksum is passed up to
      the guest.
      
      CC: Daniel Lezcano <daniel.lezcano@free.fr>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Andrian Nord <nightnord@gmail.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Michael S. Tsirkin <mst@redhat.com>
      CC: Jason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cea2f34c
    • Vlad Yasevich's avatar
      mactap: Fix checksum errors for non-gso packets in bridge mode · bdccb452
      Vlad Yasevich authored
      [ Upstream commit cbdb0427 ]
      
      The following is a problematic configuration:
      
       VM1: virtio-net device connected to macvtap0@eth0
       VM2: e1000 device connect to macvtap1@eth0
      
      The problem is is that virtio-net supports checksum offloading
      and thus sends the packets to the host with CHECKSUM_PARTIAL set.
      On the other hand, e1000 does not support any acceleration.
      
      For small TCP packets (and this includes the 3-way handshake),
      e1000 ends up receiving packets that only have a partial checksum
      set.  This causes TCP to fail checksum validation and to drop
      packets.  As a result tcp connections can not be established.
      
      Commit 3e4f8b78
      	macvtap: Perform GSO on forwarding path.
      fixes this issue for large packets wthat will end up undergoing GSO.
      This commit adds a check for the non-GSO case and attempts to
      compute the checksum for partially checksummed packets in the
      non-GSO case.
      
      CC: Daniel Lezcano <daniel.lezcano@free.fr>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Andrian Nord <nightnord@gmail.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Michael S. Tsirkin <mst@redhat.com>
      CC: Jason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdccb452
    • Karl Heiss's avatar
      net: sctp: Don't transition to PF state when transport has exhausted 'Path.Max.Retrans'. · 987c76c0
      Karl Heiss authored
      [ Upstream commit 8c2eab90 ]
      
      Don't transition to the PF state on every strike after 'Path.Max.Retrans'.
      Per draft-ietf-tsvwg-sctp-failover-03 Section 5.1.6:
      
         Additional (PMR - PFMR) consecutive timeouts on a PF destination
         confirm the path failure, upon which the destination transitions to the
         Inactive state.  As described in [RFC4960], the sender (i) SHOULD notify
         ULP about this state transition, and (ii) transmit heartbeats to the
         Inactive destination at a lower frequency as described in Section 8.3 of
         [RFC4960].
      
      This also prevents sending SCTP_ADDR_UNREACHABLE to the user as the state
      bounces between SCTP_INACTIVE and SCTP_PF for each subsequent strike.
      Signed-off-by: default avatarKarl Heiss <kheiss@gmail.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      987c76c0
    • Oliver Hartkopp's avatar
      slip: fix spinlock variant · 0e9d5992
      Oliver Hartkopp authored
      [ Upstream commit ddcde142 ]
      
      With commit cc9fa74e ("slip/slcan: added locking in wakeup function") a
      formerly missing locking was added to slip.c and slcan.c by Andre Naujoks.
      
      Alexander Stein contributed the fix 367525c8 ("can: slcan: Fix spinlock
      variant") as the kernel lock debugging advised to use spin_lock_bh() instead
      of just using spin_lock().
      
      This fix has to be applied to the same code section in slip.c for the same
      reason too.
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e9d5992
    • Bjørn Mork's avatar
      net: qmi_wwan: add a number of Dell devices · 21ff5937
      Bjørn Mork authored
      [ Upstream commit 6f10c5d1 ]
      
      Dan writes:
      
      "The Dell drivers use the same configuration for PIDs:
      
      81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
      81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
      81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
      81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
      81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card
      
      These devices are all clearly Sierra devices, but are also definitely
      Gobi-based.  The A8 might be the MC7700/7710 and A9 is likely a MC7750.
      
      >From DellGobi5kSetup.exe from the Dell drivers:
      
      usbif0: serial/firmware loader?
      usbif2: nmea
      usbif3: modem/ppp
      usbif8: net/QMI"
      Reported-by: default avatarAceLan Kao <acelan.kao@canonical.com>
      Reported-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21ff5937
    • Bjørn Mork's avatar
      net: qmi_wwan: add a number of CMOTech devices · fa395b0f
      Bjørn Mork authored
      [ Upstream commit 41be7d90 ]
      
      A number of older CMOTech modems are based on Qualcomm
      chips and exporting a QMI/wwan function.
      Reported-by: default avatarLars Melin <larsm17@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa395b0f
    • Bjørn Mork's avatar
      net: qmi_wwan: add Alcatel L800MA · 95c76ef3
      Bjørn Mork authored
      [ Upstream commit 75573660 ]
      
      Device interface layout:
      0: ff/ff/ff - serial
      1: ff/00/00 - serial AT+PPP
      2: ff/ff/ff - QMI/wwan
      3: 08/06/50 - storage
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95c76ef3
    • Bjørn Mork's avatar
      net: qmi_wwan: add Olivetti Olicard 500 · f165a889
      Bjørn Mork authored
      [ Upstream commit efc0b25c ]
      
      Device interface layout:
      0: ff/ff/ff - serial
      1: ff/ff/ff - serial AT+PPP
      2: 08/06/50 - storage
      3: ff/ff/ff - serial
      4: ff/ff/ff - QMI/wwan
      Reported-by: default avatarJulio Araujo <julio.araujo@wllctel.com.br>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f165a889
    • Bjørn Mork's avatar
      net: qmi_wwan: add Sierra Wireless MC7305/MC7355 · 8d5bb0cc
      Bjørn Mork authored
      [ Upstream commit 9214224e ]
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d5bb0cc
    • Bjørn Mork's avatar
      net: qmi_wwan: add Sierra Wireless MC73xx · 88724e6b
      Bjørn Mork authored
      [ Upstream commit 1c138607 ]
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88724e6b
    • Bjørn Mork's avatar
      net: qmi_wwan: add Sierra Wireless EM7355 · d2c3d4f3
      Bjørn Mork authored
      [ Upstream commit b85f5dea ]
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2c3d4f3
    • Xufeng Zhang's avatar
      sctp: reset flowi4_oif parameter on route lookup · 26d8db95
      Xufeng Zhang authored
      [ Upstream commit 85350871 ]
      
      commit 813b3b5d (ipv4: Use caller's on-stack flowi as-is
      in output route lookups.) introduces another regression which
      is very similar to the problem of commit e6b45241 (ipv4: reset
      flowi parameters on route connect) wants to fix:
      Before we call ip_route_output_key() in sctp_v4_get_dst() to
      get a dst that matches a bind address as the source address,
      we have already called this function previously and the flowi
      parameters have been initialized including flowi4_oif, so when
      we call this function again, the process in __ip_route_output_key()
      will be different because of the setting of flowi4_oif, and we'll
      get a networking device which corresponds to the inputted flowi4_oif
      as the output device, this is wrong because we'll never hit this
      place if the previously returned source address of dst match one
      of the bound addresses.
      
      To reproduce this problem, a vlan setting is enough:
        # ifconfig eth0 up
        # route del default
        # vconfig add eth0 2
        # vconfig add eth0 3
        # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0
        # route add default gw 10.0.1.254 dev eth0.2
        # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0
        # ip rule add from 10.0.0.14 table 4
        # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3
        # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I
      You'll detect that all the flow are routed to eth0.2(10.0.1.254).
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26d8db95
    • Toshiaki Makita's avatar
      bridge: Handle IFLA_ADDRESS correctly when creating bridge device · 4a68caa1
      Toshiaki Makita authored
      [ Upstream commit 30313a3d ]
      
      When bridge device is created with IFLA_ADDRESS, we are not calling
      br_stp_change_bridge_id(), which leads to incorrect local fdb
      management and bridge id calculation, and prevents us from receiving
      frames on the bridge device.
      Reported-by: default avatarTom Gundersen <teg@jklm.no>
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a68caa1
    • Kumar Sundararajan's avatar
      ipv6: fib: fix fib dump restart · 321dbc0d
      Kumar Sundararajan authored
      [ Upstream commit 1c265854 ]
      
      When the ipv6 fib changes during a table dump, the walk is
      restarted and the number of nodes dumped are skipped. But the existing
      code doesn't advance to the next node after a node is skipped. This can
      cause the dump to loop or produce lots of duplicates when the fib
      is modified during the dump.
      
      This change advances the walk to the next node if the current node is
      skipped after a restart.
      Signed-off-by: default avatarKumar Sundararajan <kumar@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      321dbc0d
    • David Gibson's avatar
      rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set · 657cad06
      David Gibson authored
      [ Upstream commit c53864fd ]
      
      Since 115c9b81 (rtnetlink: Fix problem with
      buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST
      attribute if they were solicited by a GETLINK message containing an
      IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag.
      
      That was done because some user programs broke when they received more data
      than expected - because IFLA_VFINFO_LIST contains information for each VF
      it can become large if there are many VFs.
      
      However, the IFLA_VF_PORTS attribute, supplied for devices which implement
      ndo_get_vf_port (currently the 'enic' driver only), has the same problem.
      It supplies per-VF information and can therefore become large, but it is
      not currently conditional on the IFLA_EXT_MASK value.
      
      Worse, it interacts badly with the existing EXT_MASK handling.  When
      IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at
      NLMSG_GOODSIZE.  If the information for IFLA_VF_PORTS exceeds this, then
      rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet.
      netlink_dump() will misinterpret this as having finished the listing and
      omit data for this interface and all subsequent ones.  That can cause
      getifaddrs(3) to enter an infinite loop.
      
      This patch addresses the problem by only supplying IFLA_VF_PORTS when
      IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      657cad06
    • David Gibson's avatar
      rtnetlink: Warn when interface's information won't fit in our packet · 22d964f5
      David Gibson authored
      [ Upstream commit 973462bb ]
      
      Without IFLA_EXT_MASK specified, the information reported for a single
      interface in response to RTM_GETLINK is expected to fit within a netlink
      packet of NLMSG_GOODSIZE.
      
      If it doesn't, however, things will go badly wrong,  When listing all
      interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first
      message in a packet as the end of the listing and omit information for
      that interface and all subsequent ones.  This can cause getifaddrs(3) to
      enter an infinite loop.
      
      This patch won't fix the problem, but it will WARN_ON() making it easier to
      track down what's going wrong.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarJiri Pirko <jpirko@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22d964f5
    • Andrew Lutomirski's avatar
      net: Fix ns_capable check in sock_diag_put_filterinfo · 265bcb0e
      Andrew Lutomirski authored
      [ Upstream commit 78541c1d ]
      
      The caller needs capabilities on the namespace being queried, not on
      their own namespace.  This is a security bug, although it likely has
      only a minor impact.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      265bcb0e
    • Vlad Yasevich's avatar
      net: sctp: cache auth_enable per endpoint · 3938b033
      Vlad Yasevich authored
      [ Upstream commit b14878cc ]
      
      Currently, it is possible to create an SCTP socket, then switch
      auth_enable via sysctl setting to 1 and crash the system on connect:
      
      Oops[#1]:
      CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.1-mipsgit-20140415 #1
      task: ffffffff8056ce80 ti: ffffffff8055c000 task.ti: ffffffff8055c000
      [...]
      Call Trace:
      [<ffffffff8043c4e8>] sctp_auth_asoc_set_default_hmac+0x68/0x80
      [<ffffffff8042b300>] sctp_process_init+0x5e0/0x8a4
      [<ffffffff8042188c>] sctp_sf_do_5_1B_init+0x234/0x34c
      [<ffffffff804228c8>] sctp_do_sm+0xb4/0x1e8
      [<ffffffff80425a08>] sctp_endpoint_bh_rcv+0x1c4/0x214
      [<ffffffff8043af68>] sctp_rcv+0x588/0x630
      [<ffffffff8043e8e8>] sctp6_rcv+0x10/0x24
      [<ffffffff803acb50>] ip6_input+0x2c0/0x440
      [<ffffffff8030fc00>] __netif_receive_skb_core+0x4a8/0x564
      [<ffffffff80310650>] process_backlog+0xb4/0x18c
      [<ffffffff80313cbc>] net_rx_action+0x12c/0x210
      [<ffffffff80034254>] __do_softirq+0x17c/0x2ac
      [<ffffffff800345e0>] irq_exit+0x54/0xb0
      [<ffffffff800075a4>] ret_from_irq+0x0/0x4
      [<ffffffff800090ec>] rm7k_wait_irqoff+0x24/0x48
      [<ffffffff8005e388>] cpu_startup_entry+0xc0/0x148
      [<ffffffff805a88b0>] start_kernel+0x37c/0x398
      Code: dd0900b8  000330f8  0126302d <dcc60000> 50c0fff1  0047182a  a48306a0
      03e00008  00000000
      ---[ end trace b530b0551467f2fd ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      
      What happens while auth_enable=0 in that case is, that
      ep->auth_hmacs is initialized to NULL in sctp_auth_init_hmacs()
      when endpoint is being created.
      
      After that point, if an admin switches over to auth_enable=1,
      the machine can crash due to NULL pointer dereference during
      reception of an INIT chunk. When we enter sctp_process_init()
      via sctp_sf_do_5_1B_init() in order to respond to an INIT chunk,
      the INIT verification succeeds and while we walk and process
      all INIT params via sctp_process_param() we find that
      net->sctp.auth_enable is set, therefore do not fall through,
      but invoke sctp_auth_asoc_set_default_hmac() instead, and thus,
      dereference what we have set to NULL during endpoint
      initialization phase.
      
      The fix is to make auth_enable immutable by caching its value
      during endpoint initialization, so that its original value is
      being carried along until destruction. The bug seems to originate
      from the very first days.
      
      Fix in joint work with Daniel Borkmann.
      Reported-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Tested-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3938b033
    • Ivan Vecera's avatar
      tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled · e91a0ef7
      Ivan Vecera authored
      The patch fixes a problem with dropped jumbo frames after usage of
      'ethtool -G ... rx'.
      
      Scenario:
      1. ip link set eth0 up
      2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo
      3. ip link set mtu 9000 dev eth0
      
      The ethtool command set rx_jumbo_pending to zero so any received jumbo
      packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N'
      to workaround the issue.
      The patch changes the logic so rx_jumbo_pending value is changed only if
      jumbo frames are enabled (MTU > 1500).
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Acked-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e91a0ef7
    • Vlad Yasevich's avatar
      macvlan: Fix lockdep warnings with stacked macvlan devices · 1c030bf1
      Vlad Yasevich authored
      [ Upstream commit c674ac30 ]
      
      Macvlan devices try to avoid stacking, but that's not always
      successfull or even desired.  As an example, the following
      configuration is perefectly legal and valid:
      
      eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1
      
      However, this configuration produces the following lockdep
      trace:
      [  115.620418] ======================================================
      [  115.620477] [ INFO: possible circular locking dependency detected ]
      [  115.620516] 3.15.0-rc1+ #24 Not tainted
      [  115.620540] -------------------------------------------------------
      [  115.620577] ip/1704 is trying to acquire lock:
      [  115.620604]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.620686]
      but task is already holding lock:
      [  115.620723]  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
      [  115.620795]
      which lock already depends on the new lock.
      
      [  115.620853]
      the existing dependency chain (in reverse order) is:
      [  115.620894]
      -> #1 (&macvlan_netdev_addr_lock_key){+.....}:
      [  115.620935]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.620974]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621019]        [<ffffffffa07296c3>] vlan_dev_set_rx_mode+0x53/0x110 [8021q]
      [  115.621066]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621105]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621143]        [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      [  115.621174]
      -> #0 (&vlan_netdev_addr_lock_key/1){+.....}:
      [  115.621174]        [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
      [  115.621174]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.621174]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621174]        [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.621174]        [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
      [  115.621174]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621174]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621174]        [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      [  115.621174]
      other info that might help us debug this:
      
      [  115.621174]  Possible unsafe locking scenario:
      
      [  115.621174]        CPU0                    CPU1
      [  115.621174]        ----                    ----
      [  115.621174]   lock(&macvlan_netdev_addr_lock_key);
      [  115.621174]                                lock(&vlan_netdev_addr_lock_key/1);
      [  115.621174]                                lock(&macvlan_netdev_addr_lock_key);
      [  115.621174]   lock(&vlan_netdev_addr_lock_key/1);
      [  115.621174]
       *** DEADLOCK ***
      
      [  115.621174] 2 locks held by ip/1704:
      [  115.621174]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815e6dbb>] rtnetlink_rcv+0x1b/0x40
      [  115.621174]  #1:  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
      [  115.621174]
      stack backtrace:
      [  115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24
      [  115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
      [  115.621174]  ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0
      [  115.621174]  ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8
      [  115.621174]  0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230
      [  115.621174] Call Trace:
      [  115.621174]  [<ffffffff816ee20c>] dump_stack+0x4d/0x66
      [  115.621174]  [<ffffffff816e9e1b>] print_circular_bug+0x200/0x20e
      [  115.621174]  [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
      [  115.621174]  [<ffffffff810d3172>] ? trace_hardirqs_on_caller+0xb2/0x1d0
      [  115.621174]  [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
      [  115.621174]  [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621174]  [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621174]  [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]  [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]  [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]  [<ffffffff811e1db1>] ? mem_cgroup_bad_page_check+0x21/0x30
      [  115.621174]  [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]  [<ffffffff810d394c>] ? __lock_acquire+0x37c/0x1a60
      [  115.621174]  [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]  [<ffffffff815ea169>] ? rtnl_newlink+0xe9/0x730
      [  115.621174]  [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]  [<ffffffff810d329d>] ? trace_hardirqs_on+0xd/0x10
      [  115.621174]  [<ffffffff815e6dbb>] ? rtnetlink_rcv+0x1b/0x40
      [  115.621174]  [<ffffffff815e6de0>] ? rtnetlink_rcv+0x40/0x40
      [  115.621174]  [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]  [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]  [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]  [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]  [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
      [  115.621174]  [<ffffffff8119d4f8>] ? might_fault+0xa8/0xb0
      [  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
      [  115.621174]  [<ffffffff815cb51e>] ? verify_iovec+0x5e/0xe0
      [  115.621174]  [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]  [<ffffffff816faa0d>] ? __do_page_fault+0x11d/0x570
      [  115.621174]  [<ffffffff810cfe9f>] ? up_read+0x1f/0x40
      [  115.621174]  [<ffffffff816fab04>] ? __do_page_fault+0x214/0x570
      [  115.621174]  [<ffffffff8120a10b>] ? mntput_no_expire+0x6b/0x1c0
      [  115.621174]  [<ffffffff8120a0b7>] ? mntput_no_expire+0x17/0x1c0
      [  115.621174]  [<ffffffff8120a284>] ? mntput+0x24/0x40
      [  115.621174]  [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]  [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]  [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      
      Fix this by correctly providing macvlan lockdep class.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c030bf1
    • Vlad Yasevich's avatar
      vlan: Fix lockdep warning with stacked vlan devices. · 102e103f
      Vlad Yasevich authored
      [ Upstream commit d38569ab ]
      
      This reverts commit dc8eaaa0.
      	vlan: Fix lockdep warning when vlan dev handle notification
      
      Instead we use the new new API to find the lock subclass of
      our vlan device.  This way we can support configurations where
      vlans are interspersed with other devices:
        bond -> vlan -> macvlan -> vlan
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      102e103f
    • Vlad Yasevich's avatar
      net: Allow for more then a single subclass for netif_addr_lock · d0166f81
      Vlad Yasevich authored
      [ Upstream commit 25175ba5 ]
      
      Currently netif_addr_lock_nested assumes that there can be only
      a single nesting level between 2 devices.  However, if we
      have multiple devices of the same type stacked, this fails.
      For example:
       eth0 <-- vlan0.10 <-- vlan0.10.20
      
      A more complicated configuration may stack more then one type of
      device in different order.
      Ex:
        eth0 <-- vlan0.10 <-- macvlan0 <-- vlan1.10.20 <-- macvlan1
      
      This patch adds an ndo_* function that allows each stackable
      device to report its nesting level.  If the device doesn't
      provide this function default subclass of 1 is used.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0166f81
    • Vlad Yasevich's avatar
      net: Find the nesting level of a given device by type. · 69ab2a8b
      Vlad Yasevich authored
      [ Upstream commit 4085ebe8 ]
      
      Multiple devices in the kernel can be stacked/nested and they
      need to know their nesting level for the purposes of lockdep.
      This patch provides a generic function that determines a nesting
      level of a particular device by its type (ex: vlan, macvlan, etc).
      We only care about nesting of the same type of devices.
      
      For example:
        eth0 <- vlan0.10 <- macvlan0 <- vlan1.20
      
      The nesting level of vlan1.20 would be 1, since there is another vlan
      in the stack under it.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69ab2a8b
    • dingtianhong's avatar
      vlan: Fix lockdep warning when vlan dev handle notification · e2c7f968
      dingtianhong authored
      [ Upstream commit dc8eaaa0 ]
      
      When I open the LOCKDEP config and run these steps:
      
      modprobe 8021q
      vconfig add eth2 20
      vconfig add eth2.20 30
      ifconfig eth2 xx.xx.xx.xx
      
      then the Call Trace happened:
      
      [32524.386288] =============================================
      [32524.386293] [ INFO: possible recursive locking detected ]
      [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G           O
      [32524.386302] ---------------------------------------------
      [32524.386306] ifconfig/3103 is trying to acquire lock:
      [32524.386310]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386326]
      [32524.386326] but task is already holding lock:
      [32524.386330]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386341]
      [32524.386341] other info that might help us debug this:
      [32524.386345]  Possible unsafe locking scenario:
      [32524.386345]
      [32524.386350]        CPU0
      [32524.386352]        ----
      [32524.386354]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386359]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386364]
      [32524.386364]  *** DEADLOCK ***
      [32524.386364]
      [32524.386368]  May be due to missing lock nesting notation
      [32524.386368]
      [32524.386373] 2 locks held by ifconfig/3103:
      [32524.386376]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81431d42>] rtnl_lock+0x12/0x20
      [32524.386387]  #1:  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386398]
      [32524.386398] stack backtrace:
      [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G           O 3.14.0-rc2-0.7-default+ #35
      [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [32524.386414]  ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
      [32524.386421]  ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
      [32524.386428]  000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
      [32524.386435] Call Trace:
      [32524.386441]  [<ffffffff814f68a2>] dump_stack+0x6a/0x78
      [32524.386448]  [<ffffffff810a35fb>] __lock_acquire+0x7ab/0x1940
      [32524.386454]  [<ffffffff810a323a>] ? __lock_acquire+0x3ea/0x1940
      [32524.386459]  [<ffffffff810a4874>] lock_acquire+0xe4/0x110
      [32524.386464]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386471]  [<ffffffff814fc07a>] _raw_spin_lock_nested+0x2a/0x40
      [32524.386476]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386481]  [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386489]  [<ffffffffa0500cab>] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
      [32524.386495]  [<ffffffff8141addf>] __dev_set_rx_mode+0x5f/0xb0
      [32524.386500]  [<ffffffff8141af8b>] dev_set_rx_mode+0x2b/0x40
      [32524.386506]  [<ffffffff8141b3cf>] __dev_open+0xef/0x150
      [32524.386511]  [<ffffffff8141b177>] __dev_change_flags+0xa7/0x190
      [32524.386516]  [<ffffffff8141b292>] dev_change_flags+0x32/0x80
      [32524.386524]  [<ffffffff8149ca56>] devinet_ioctl+0x7d6/0x830
      [32524.386532]  [<ffffffff81437b0b>] ? dev_ioctl+0x34b/0x660
      [32524.386540]  [<ffffffff814a05b0>] inet_ioctl+0x80/0xa0
      [32524.386550]  [<ffffffff8140199d>] sock_do_ioctl+0x2d/0x60
      [32524.386558]  [<ffffffff81401a52>] sock_ioctl+0x82/0x2a0
      [32524.386568]  [<ffffffff811a7123>] do_vfs_ioctl+0x93/0x590
      [32524.386578]  [<ffffffff811b2705>] ? rcu_read_lock_held+0x45/0x50
      [32524.386586]  [<ffffffff811b39e5>] ? __fget_light+0x105/0x110
      [32524.386594]  [<ffffffff811a76b1>] SyS_ioctl+0x91/0xb0
      [32524.386604]  [<ffffffff815057e2>] system_call_fastpath+0x16/0x1b
      
      ========================================================================
      
      The reason is that all of the addr_lock_key for vlan dev have the same class,
      so if we change the status for vlan dev, the vlan dev and its real dev will
      hold the same class of addr_lock_key together, so the warning happened.
      
      we should distinguish the lock depth for vlan dev and its real dev.
      
      v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
      	could support to add 8 vlan id on a same vlan dev, I think it is enough for current
      	scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
      	and the vlan dev would not meet the same class key with its real dev.
      
      	The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
      	dev could get a suitable class key.
      
      v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
      	and its real dev, but it make no sense, because the difference for subclass in the
      	lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
      	to distinguish the different depth for every vlan dev, the same depth of the vlan dev
      	could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
      	I think it is enough here, the lockdep should never exceed that value.
      
      v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
      	we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
      	and use the depth as the subclass for addr_lock_key.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2c7f968