linux-stable.git/drivers/net/bonding, branch v3.16.65

bonding: do not set slave_dev npinfo before slave_enable_netpoll in bond_enslave

2018-10-21T07:45:39+00:00

commit ddea788c63094f7c483783265563dd5b50052e28 upstream.

After Commit 8a8efa22f51b ("bonding: sync netpoll code with bridge"), it
would set slave_dev npinfo in slave_enable_netpoll when enslaving a dev
if bond->dev->npinfo was set.

However now slave_dev npinfo is set with bond->dev->npinfo before calling
slave_enable_netpoll. With slave_dev npinfo set, __netpoll_setup called
in slave_enable_netpoll will not call slave dev's .ndo_netpoll_setup().
It causes that the lower dev of this slave dev can't set its npinfo.

One way to reproduce it:

  # modprobe bonding
  # brctl addbr br0
  # brctl addif br0 eth1
  # ifconfig bond0 192.168.122.1/24 up
  # ifenslave bond0 eth2
  # systemctl restart netconsole
  # ifenslave bond0 br0
  # ifconfig eth2 down
  # systemctl restart netconsole

The netpoll won't really work.

This patch is to remove that slave_dev npinfo setting in bond_enslave().

Fixes: 8a8efa22f51b ("bonding: sync netpoll code with bridge")
Signed-off-by: Xin Long 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

bonding: process the err returned by dev_set_allmulti properly in bond_enslave

2018-06-16T21:22:49+00:00

commit 9f5a90c107741b864398f4ac0014711a8c1d8474 upstream.

When dev_set_promiscuity(1) succeeds but dev_set_allmulti(1) fails,
dev_set_promiscuity(-1) should be done before going to the err path.
Otherwise, dev->promiscuity will leak.

Fixes: 7e1a1ac1fbaa ("bonding: Check return of dev_set_promiscuity/allmulti")
Signed-off-by: Xin Long 
Acked-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave

2018-06-16T21:22:49+00:00

commit ae42cc62a9f07f1f6979054ed92606b9c30f4a2e upstream.

Beniamino found a crash when adding vlan as slave of bond which is also
the parent link:

  ip link add bond1 type bond
  ip link set bond1 up
  ip link add link bond1 vlan1 type vlan id 80
  ip link set vlan1 master bond1

The call trace is as below:

  [] queued_spin_lock_slowpath+0xb/0xf
  [] _raw_spin_lock+0x20/0x30
  [] dev_mc_sync+0x37/0x80
  [] vlan_dev_set_rx_mode+0x1c/0x30 [8021q]
  [] __dev_set_rx_mode+0x5a/0xa0
  [] dev_mc_sync_multiple+0x78/0x80
  [] bond_enslave+0x67c/0x1190 [bonding]
  [] do_setlink+0x9c9/0xe50
  [] rtnl_newlink+0x522/0x880
  [] rtnetlink_rcv_msg+0xa7/0x260
  [] netlink_rcv_skb+0xab/0xc0
  [] rtnetlink_rcv+0x28/0x30
  [] netlink_unicast+0x170/0x210
  [] netlink_sendmsg+0x308/0x420
  [] sock_sendmsg+0xb6/0xf0

This is actually a dead lock caused by sync slave hwaddr from master when
the master is the slave's 'slave'. This dead loop check is actually done
by netdev_master_upper_dev_link. However, Commit 1f718f0f4f97 ("bonding:
populate neighbour's private on enslave") moved it after dev_mc_sync.

This patch is to fix it by moving dev_mc_sync after master_upper_dev_link,
so that this loop check would be earlier than dev_mc_sync. It also moves
if (mode == BOND_MODE_8023AD) into if (!bond_uses_primary) clause as an
improvement.

Note team driver also has this issue, I will fix it in another patch.

Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Reported-by: Beniamino Galvani 
Signed-off-by: Xin Long 
Acked-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

bonding: fix the err path for dev hwaddr sync in bond_enslave

2018-06-16T21:22:49+00:00

commit 5c78f6bfae2b10ff70e21d343e64584ea6280c26 upstream.

vlan_vids_add_by_dev is called right after dev hwaddr sync, so on
the err path it should unsync dev hwaddr. Otherwise, the slave
dev's hwaddr will never be unsync when this err happens.

Fixes: 1ff412ad7714 ("bonding: change the bond's vlan syncing functions with the standard ones")
Signed-off-by: Xin Long 
Reviewed-by: Nikolay Aleksandrov 
Acked-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

bonding: set carrier off for devices created through netlink

2017-03-16T02:27:18+00:00

[ Upstream commit 005db31d5f5f7c31cfdc43505d77eb3ca5cf8ec6 ]

Commit e826eafa65c6 ("bonding: Call netif_carrier_off after
register_netdevice") moved netif_carrier_off() from bond_init() to
bond_create(), but the latter is called only for initial default
devices and ones created through sysfs:

 $ modprobe bonding
 $ echo +bond1 > /sys/class/net/bonding_masters
 $ ip link add bond2 type bond
 $ grep "MII Status" /proc/net/bonding/*
 /proc/net/bonding/bond0:MII Status: down
 /proc/net/bonding/bond1:MII Status: down
 /proc/net/bonding/bond2:MII Status: up

Ensure that carrier is initially off also for devices created through
netlink.

Signed-off-by: Beniamino Galvani 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

bonding: prevent out of bound accesses

2016-08-22T21:38:25+00:00

commit f87fda00b6ed232a817c655b8d179b48bde8fdbe upstream.

ether_addr_equal_64bits() requires some care about its arguments,
namely that 8 bytes might be read, even if last 2 byte values are not
used.

KASan detected a violation with null_mac_addr and lacpdu_mcast_addr
in bond_3ad.c

Same problem with mac_bcast[] and mac_v6_allmcast[] in bond_alb.c :
Although the 8-byte alignment was there, KASan would detect out
of bound accesses.

Fixes: 815117adaf5b ("bonding: use ether_addr_equal_unaligned for bond addr compare")
Fixes: bb54e58929f3 ("bonding: Verify RX LACPDU has proper dest mac-addr")
Fixes: 885a136c52a8 ("bonding: use compare_ether_addr_64bits() in ALB")
Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Acked-by: Dmitry Vyukov 
Acked-by: Nikolay Aleksandrov 
Acked-by: Ding Tianhong 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16:
 - Adjust filename
 - Drop change to bond_params::ad_actor_system
 - Fix one more copy of null_mac_addr to use eth_zero_addr()]
Signed-off-by: Ben Hutchings

bonding: Fix ARP monitor validation

2016-03-08T12:15:37+00:00

commit 21a75f0915dde8674708b39abfcda113911c49b1 upstream.

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: aeea64ac717a ("bonding: don't trust arp requests unless active slave really works")
Cc: Veaceslav Falico 
Cc: Andy Gospodarek 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

bonding: Prevent IPv6 link local address on enslaved devices

2016-01-28T10:50:47+00:00

commit 03d84a5f83a67e692af00a3d3901e7820e3e84d5 upstream.

Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
undoes the fix provided by commit c2edacf80e15 ("bonding / ipv6: no addrconf
for slaves separately from master") by effectively setting the slave flag
after the slave has been opened.  If the slave comes up quickly enough, it
will go through the IPv6 addrconf before the slave flag has been set and
will get a link local IPv6 address.

In order to ensure that addrconf knows to ignore the slave devices on state
change, set IFF_SLAVE before dev_open() during bonding enslavement.

Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Signed-off-by: Karl Heiss 
Signed-off-by: Jay Vosburgh 
Reviewed-by: Jarod Wilson 
Signed-off-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

bonding: fix panic on non-ARPHRD_ETHER enslave failure

2015-12-13T17:49:44+00:00

commit 40baec225765c54eefa870530dd613bad9829bb7 upstream.

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 
Signed-off-by: Jay Vosburgh 
Fixes: 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")
Acked-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

bonding: correct the MAC address for "follow" fail_over_mac policy

2015-08-27T13:05:32+00:00

commit a951bc1e6ba58f11df5ed5ddc41311e10f5fd20b upstream.

The "follow" fail_over_mac policy is useful for multiport devices that
either become confused or incur a performance penalty when multiple
ports are programmed with the same MAC address, but the same MAC
address still may happened by this steps for this policy:

1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
   bond0 has the same mac address with eth0, it is MAC1.

2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
   eth1 is backup, eth1 has MAC2.

3) ifconfig eth0 down
   eth1 became active slave, bond will swap MAC for eth0 and eth1,
   so eth1 has MAC1, and eth0 has MAC2.

4) ifconfig eth1 down
   there is no active slave, and eth1 still has MAC1, eth2 has MAC2.

5) ifconfig eth0 up
   the eth0 became active slave again, the bond set eth0 to MAC1.

Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
MAC address, it will break this policy for ACTIVE_BACKUP mode.

This patch will fix this problem by finding the old active slave and
swap them MAC address before change active slave.

Signed-off-by: Ding Tianhong 
Tested-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
[ luis: backported to 3.16: used davem's backport to 3.14 ]
Signed-off-by: Luis Henriques