linux/drivers/net/bonding, branch v3.0.79

bonding: IFF_BONDING is not stripped on enslave failure

2013-05-01T15:56:37Z

[ Upstream commit b6a5a7b9a528a8b4c8bec940b607c5dd9102b8cc ] While enslaving a new device and after IFF_BONDING flag is set, in case of failure it is not stripped from the device's priv_flags while cleaning up, which could lead to other problems. Cleaning at err_close because the flag is set after dev_open(). v2: no change Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: get netdev_rx_handler_unregister out of locks

2013-04-05T17:16:54Z

[ Upstream commit fcd99434fb5c137274d2e15dd2a6a7455f0f29ff ] Now that netdev_rx_handler_unregister contains synchronize_net(), we need to call it outside of bond->lock, cause it might sleep. Also, remove the already unneded synchronize_net(). Signed-off-by: Veaceslav Falico Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: fix race condition in bonding_store_slaves_active

2013-01-11T17:03:35Z

[ Upstream commit e196c0e579902f42cf72414461fb034e5a1ffbf7 ] Race between bonding_store_slaves_active() and slave manipulation functions. The bond_for_each_slave use in bonding_store_slaves_active() is not protected by any synchronization mechanism. NULL pointer dereference is easy to reach. Fixed by acquiring the bond->lock for the slave walk. v2: Make description text < 75 columns Signed-off-by: Nikolay Aleksandrov Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.

2013-01-11T17:03:34Z

[ Upstream commit 0e376bd0b791ac6ac6bdb051492df0769c840848 ] Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices during enslave and detach. Signed-off-by: Sarveshwar Bandi Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: Fix corrupted queue_mapping

2012-07-16T15:47:37Z

[ Upstream commit 5ee31c6898ea5537fcea160999d60dc63bc0c305 ] In the transmit path of the bonding driver, skb->cb is used to stash the skb->queue_mapping so that the bonding device can set its own queue mapping. This value becomes corrupted since the skb->cb is also used in __dev_xmit_skb. When transmitting through bonding driver, bond_select_queue is called from dev_queue_xmit. In bond_select_queue the original skb->queue_mapping is copied into skb->cb (via bond_queue_mapping) and skb->queue_mapping is overwritten with the bond driver queue. Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes the packet length into skb->cb, thereby overwriting the stashed queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit), the queue mapping for the skb is set to the stashed value which is now the skb length and hence is an invalid queue for the slave device. If we want to save skb->queue_mapping into skb->cb[], best place is to add a field in struct qdisc_skb_cb, to make sure it wont conflict with other layers (eg : Qdiscc, Infiniband...) This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8 bytes : netem qdisc for example assumes it can store an u64 in it, without misalignment penalty. Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[]. The largest user is CHOKe and it fills it. Based on a previous patch from Tom Herbert. Signed-off-by: Eric Dumazet Reported-by: Tom Herbert Cc: John Fastabend Cc: Roland Dreier Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: properly unset current_arp_slave on slave link up

2012-04-27T16:51:19Z

[ Upstream commit 5a4309746cd74734daa964acb02690c22b3c8911 ] When a slave comes up, we're unsetting the current_arp_slave without removing active flags from it, which can lead to situations where we have more than one slave with active flags in active-backup mode. To avoid this situation we must remove the active flags from a slave before removing it as a current_arp_slave. Signed-off-by: Veaceslav Falico Signed-off-by: Jay Vosburgh Signed-off-by: Andy Gospodarek Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: fix enslaving in alb mode when link down

2012-02-03T17:19:03Z

[ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ] bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC address. This is done differently for TLB and ALB modes. bond->alb_info.rlb_enabled is used to discriminate between the two modes but this flag may be uninitialized if the slave is being enslaved prior to calling bond_open() -> bond_alb_initialize() on the master. It turns out all the callers of alb_set_slave_mac_addr() pass bond->alb_info.rlb_enabled as the hw parameter. This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and makes the function decide based on the bonding mode instead, which fixes the above problem. Reported-by: Narendra K Signed-off-by: Jiri Bohac Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: fix error handling if slave is busy (v2)

2012-01-12T19:35:44Z

commit f7d9821a6a9c83450ac35e76d3709e32fd38b76f upstream. If slave device already has a receive handler registered, then the error unwind of bonding device enslave function is broken. The following will leave a pointer to freed memory in the slave device list, causing a later kernel panic. # modprobe dummy # ip li add dummy0-1 link dummy0 type macvlan # modprobe bonding # echo +dummy0 >/sys/class/net/bond0/bonding/slaves The fix is to detach the slave (which removes it from the list) in the unwind path. Signed-off-by: Stephen Hemminger Reviewed-by: Nicolas de Pesloüan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: use local function pointer of bond->recv_probe in bond_handle_frame

2011-11-11T17:36:24Z

[ Upstream commit 4d97480b1806e883eb1c7889d4e7a87e936e06d9 ] The bond->recv_probe is called in bond_handle_frame() when a packet is received, but bond_close() sets it to NULL. So, a panic occurs when both functions work in parallel. Why this happen: After null pointer check of bond->recv_probe, an sk_buff is duplicated and bond->recv_probe is called in bond_handle_frame. So, a panic occurs when bond_close() is called between the check and call of bond->recv_probe. Patch: This patch uses a local function pointer of bond->recv_probe in bond_handle_frame(). So, it can avoid the null pointer dereference. Signed-off-by: Mitsuo Hayasaka Cc: Jay Vosburgh Cc: Andy Gospodarek Cc: Eric Dumazet Cc: WANG Cong Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: fix string comparison errors

2011-08-16T01:31:38Z

[ Upstream commit f4bb2e9c4fa9e5fdddf90589703613fd1a9c519f ] When a bond contains a device where one name is the subset of another (eth1 and eth10, for example), one cannot properly set the primary device or the currently active device. This was reported and based on work by Takuma Umeya. I also verified the problem and tested that this fix resolves it. V2: A few did not like the the current code or my changes, so I refactored bonding_store_primary and bonding_store_active_slave to be a bit cleaner, dropped the use of strnicmp since we did not really need the comparison to be case insensitive, and formatted the input string from sysfs so a comparison to IFNAMSIZ could be used. I also discovered an error in bonding_store_active_slave that would modify bond->primary_slave rather than bond->curr_active_slave before forcing the bonding driver to choose a new active slave. V3: Actually sending the proper patch.... Signed-off-by: Andy Gospodarek Reported-by: Takuma Umeya Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman