1. 28 Apr, 2017 1 commit
    • Paolo Abeni's avatar
      bonding: avoid defaulting hard_header_len to ETH_HLEN on slave removal · 19cdead3
      Paolo Abeni authored
      On slave list updates, the bonding driver computes its hard_header_len
      as the maximum of all enslaved devices's hard_header_len.
      If the slave list is empty, e.g. on last enslaved device removal,
      ETH_HLEN is used.
      
      Since the bonding header_ops are set only when the first enslaved
      device is attached, the above can lead to header_ops->create()
      being called with the wrong skb headroom in place.
      
      If bond0 is configured on top of ipoib devices, with the
      following commands:
      
      ifup bond0
      for slave in $BOND_SLAVES_LIST; do
      	ip link set dev $slave nomaster
      done
      ping -c 1 <ip on bond0 subnet>
      
      we will obtain a skb_under_panic() with a similar call trace:
      	skb_push+0x3d/0x40
      	push_pseudo_header+0x17/0x30 [ib_ipoib]
      	ipoib_hard_header+0x4e/0x80 [ib_ipoib]
      	arp_create+0x12f/0x220
      	arp_send_dst.part.19+0x28/0x50
      	arp_solicit+0x115/0x290
      	neigh_probe+0x4d/0x70
      	__neigh_event_send+0xa7/0x230
      	neigh_resolve_output+0x12e/0x1c0
      	ip_finish_output2+0x14b/0x390
      	ip_finish_output+0x136/0x1e0
      	ip_output+0x76/0xe0
      	ip_local_out+0x35/0x40
      	ip_send_skb+0x19/0x40
      	ip_push_pending_frames+0x33/0x40
      	raw_sendmsg+0x7d3/0xb50
      	inet_sendmsg+0x31/0xb0
      	sock_sendmsg+0x38/0x50
      	SYSC_sendto+0x102/0x190
      	SyS_sendto+0xe/0x10
      	do_syscall_64+0x67/0x180
      	entry_SYSCALL64_slow_path+0x25/0x25
      
      This change addresses the issue avoiding updating the bonding device
      hard_header_len when the slaves list become empty, forbidding to
      shrink it below the value used by header_ops->create().
      
      The bug is there since commit 54ef3137 ("[PATCH] bonding: Handle large
      hard_header_len") but the panic can be triggered only since
      commit fc791b63
      
       ("IB/ipoib: move back IB LL address into the hard
      header").
      Reported-by: default avatarNorbert P <noe@physik.uzh.ch>
      Fixes: 54ef3137 ("[PATCH] bonding: Handle large hard_header_len")
      Fixes: fc791b63
      
       ("IB/ipoib: move back IB LL address into the hard header")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19cdead3
  2. 02 Mar, 2017 1 commit
  3. 06 Feb, 2017 1 commit
  4. 03 Feb, 2017 1 commit
  5. 08 Jan, 2017 1 commit
  6. 18 Nov, 2016 1 commit
    • Alexey Dobriyan's avatar
      netns: make struct pernet_operations::id unsigned int · c7d03a00
      Alexey Dobriyan authored
      Make struct pernet_operations::id unsigned.
      
      There are 2 reasons to do so:
      
      1)
      This field is really an index into an zero based array and
      thus is unsigned entity. Using negative value is out-of-bound
      access by definition.
      
      2)
      On x86_64 unsigned 32-bit data which are mixed with pointers
      via array indexing or offsets added or subtracted to pointers
      are preffered to signed 32-bit data.
      
      "int" being used as an array index needs to be sign-extended
      to 64-bit before being used.
      
      	void f(long *p, int i)
      	{
      		g(p[i]);
      	}
      
        roughly translates to
      
      	movsx	rsi, esi
      	mov	rdi, [rsi+...]
      	call 	g
      
      MOVSX is 3 byte instruction which isn't necessary if the variable is
      unsigned because x86_64 is zero extending by default.
      
      Now, there is net_generic() function which, you guessed it right, uses
      "int" as an array index:
      
      	static inline void *net_generic(const struct net *net, int id)
      	{
      		...
      		ptr = ng->ptr[id - 1];
      		...
      	}
      
      And this function is used a lot, so those sign...
      c7d03a00
  7. 30 Oct, 2016 1 commit
  8. 18 Oct, 2016 1 commit
  9. 28 Sep, 2016 1 commit
    • Al Viro's avatar
      bonding: quit messing with IOCTL · 4ad41c1e
      Al Viro authored
      
      
      The only remaining users are issuing SIOCGMIIPHY and SIOCGMIIREG,
      neither of which deals with userland pointers.  Simply calling
      ->ndo_do_ioctl() is fine; no messing with set_fs() is needed.
      It used to mess with SIOCETHTOOL, which would've needed set_fs(),
      but that has been killed in "[NET] ethtool ops are the only way"
      9 years ago...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4ad41c1e
  10. 04 Sep, 2016 1 commit
    • Mahesh Bandewar's avatar
      bonding: Fix bonding crash · 24b27fc4
      Mahesh Bandewar authored
      
      
      Following few steps will crash kernel -
      
        (a) Create bonding master
            > modprobe bonding miimon=50
        (b) Create macvlan bridge on eth2
            > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
      	   type macvlan
        (c) Now try adding eth2 into the bond
            > echo +eth2 > /sys/class/net/bond0/bonding/slaves
            <crash>
      
      Bonding does lots of things before checking if the device enslaved is
      busy or not.
      
      In this case when the notifier call-chain sends notifications, the
      bond_netdev_event() assumes that the rx_handler /rx_handler_data is
      registered while the bond_enslave() hasn't progressed far enough to
      register rx_handler for the new slave.
      
      This patch adds a rx_handler check that can be performed right at the
      beginning of the enslave code to avoid getting into this situation.
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24b27fc4
  11. 01 Sep, 2016 1 commit
  12. 09 Aug, 2016 1 commit
  13. 25 Jul, 2016 1 commit
  14. 05 Jul, 2016 2 commits
  15. 09 Jun, 2016 1 commit
  16. 07 Jun, 2016 1 commit
  17. 19 Mar, 2016 2 commits
  18. 26 Feb, 2016 1 commit
  19. 16 Feb, 2016 1 commit
    • Jay Vosburgh's avatar
      bonding: don't use stale speed and duplex information · 266b495f
      Jay Vosburgh authored
      There is presently a race condition between the bonding periodic
      link monitor and the updating of a slave's speed and duplex.  The former
      occurs on a periodic basis, and the latter in response to a driver's
      calling of netif_carrier_on.
      
      	It is possible for the periodic monitor to run between the
      driver call of netif_carrier_on and the receipt of the NETDEV_CHANGE
      event that causes bonding to update the slave's speed and duplex.  This
      manifests most notably as a report that a slave is up and "0 Mbps full
      duplex" after enslavement, but in principle could report an incorrect
      speed and duplex after any link up event if the device comes up with a
      different speed or duplex.  This affects the 802.3ad aggregator
      selection, as the speed and duplex are selection criteria.
      
      	This is fixed by updating the speed and duplex in the periodic
      monitor, prior to using that information.
      
      	This was done historically in bonding, but the call to
      bond_update_speed_duplex was removed in commit 876254ae ("bonding:
      don't call update_speed_duplex() under spinlocks"), as it might sleep
      under lock.  Later, the locking was changed to only hold RTNL, and so
      after commit 876254ae
      
       ("bonding: don't call update_speed_duplex()
      under spinlocks") this call is again safe.
      Tested-by: default avatar"Tantilov, Emil S" <emil.s.tantilov@intel.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: dingtianhong <dingtianhong@huawei.com>
      Fixes: 876254ae
      
       ("bonding: don't call update_speed_duplex() under spinlocks")
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Acked-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      266b495f
  20. 13 Feb, 2016 1 commit
    • Jay Vosburgh's avatar
      bonding: Fix ARP monitor validation · 21a75f09
      Jay Vosburgh authored
      The current logic in bond_arp_rcv will accept an incoming ARP for
      validation if (a) the receiving slave is either "active" (which includes
      the currently active slave, or the current ARP slave) or, (b) there is a
      currently active slave, and it has received an ARP since it became active.
      For case (b), the receiving slave isn't the currently active slave, and is
      receiving the original broadcast ARP request, not an ARP reply from the
      target.
      
      	This logic can fail if there is no currently active slave.  In
      this situation, the ARP probe logic cycles through all slaves, assigning
      each in turn as the "current_arp_slave" for one arp_interval, then setting
      that one as "active," and sending an ARP probe from that slave.  The
      current logic expects the ARP reply to arrive on the sending
      current_arp_slave, however, due to switch FDB updating delays, the reply
      may be directed to another slave.
      
      	This can arise if the bonding slaves and switch are working, but
      the ARP target is not responding.  When the ARP target recovers, a
      condition may result wherein the ARP target host replies faster than the
      switch can update its forwarding table, causing each ARP reply to be sent
      to the previous current_arp_slave.  This will never pass the logic in
      bond_arp_rcv, as neither of the above conditions (a) or (b) are met.
      
      	Some experimentation on a LAN shows ARP reply round trips in the
      200 usec range, but my available switches never update their FDB in less
      than 4000 usec.
      
      	This patch changes the logic in bond_arp_rcv to additionally
      accept an ARP reply for validation on any slave if there is a current ARP
      slave and it sent an ARP probe during the previous arp_interval.
      
      Fixes: aeea64ac
      
       ("bonding: don't trust arp requests unless active slave really works")
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21a75f09
  21. 11 Feb, 2016 1 commit
  22. 08 Feb, 2016 1 commit
  23. 06 Feb, 2016 2 commits
  24. 11 Jan, 2016 1 commit
  25. 15 Dec, 2015 1 commit
    • Tom Herbert's avatar
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert authored
      
      
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a188222b
  26. 04 Dec, 2015 1 commit
  27. 03 Dec, 2015 6 commits
  28. 07 Nov, 2015 1 commit
    • Jay Vosburgh's avatar
      bonding: fix panic on non-ARPHRD_ETHER enslave failure · 40baec22
      Jay Vosburgh authored
      
      
      Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
      are not ARPHRD_ETHER, if needed, it resets the bonding device back to
      ARPHRD_ETHER by calling ether_setup.
      
      	Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
      if the bond device is up, leaving it in a quasi-down state without
      having actually gone through dev_close.  For bonding, if any periodic
      work queue items are active (miimon, arp_interval, etc), those will
      remain running, as they are stopped by bond_close.  At this point, if
      the bonding module is unloaded or the bond is deleted, the system will
      panic when the work function is called.
      
      	This panic is resolved by calling dev_close on the bond itself
      prior to calling ether_setup.
      
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 7d5cd2ce
      
       ("bonding: correctly handle bonding type change on enslave failure")
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40baec22
  29. 03 Nov, 2015 1 commit
  30. 16 Oct, 2015 1 commit
  31. 18 Sep, 2015 1 commit
    • Eric Dumazet's avatar
      bonding: use l4 hash if available · 4b1b865e
      Eric Dumazet authored
      
      
      If skb carries a l4 hash, no need to perform a flow dissection.
      
      Performance is slightly better :
      
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39012e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39393e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39988e+06
      
      After patch :
      
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.43579e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.44304e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.44312e+06
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b1b865e
  32. 01 Sep, 2015 1 commit