linux-stable.git/drivers/net/team, branch v3.12.52

team: don't traverse port list using rcu in team_set_mac_address

2015-03-12T09:06:29+00:00

[ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ]

Currently the list is traversed using rcu variant. That is not correct
since dev_set_mac_address can be called which eventually calls
rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this
by remove the rcu usage here.

Fixes: 3d249d4ca7 "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: fix possible null pointer dereference in team_handle_frame

2015-03-12T09:06:27+00:00

[ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ]

Currently following race is possible in team:

CPU0                                        CPU1
                                            team_port_del
                                              team_upper_dev_unlink
                                                priv_flags &= ~IFF_TEAM_PORT
team_handle_frame
  team_port_get_rcu
    team_port_exists
      priv_flags & IFF_TEAM_PORT == 0
    return NULL (instead of port got
                 from rx_handler_data)
                                              netdev_rx_handler_unregister

The thing is that the flag is removed before rx_handler is unregistered.
If team_handle_frame is called in between, team_port_exists returns 0
and team_port_get_rcu will return NULL.
So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
that team_handle_frame will always see valid rx_handler_data pointer.

Signed-off-by: Jiri Pirko 
Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin

2015-01-26T13:39:18+00:00

[ Upstream commit b0d11b42785b70e19bc6a3122eead3f7969a7589 ]

This patch is fixing a race condition that may cause setting
count_pending to -1, which results in unwanted big bulk of arp messages
(in case of "notify peers").

Consider following scenario:

count_pending == 2
   CPU0                                           CPU1
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
 team_notify_peers
   atomic_add (adding 1 to count_pending)
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 0)
   schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to -1)

Fix this race by using atomic_dec_if_positive - that will prevent
count_pending running under 0.

Fixes: fc423ff00df3a1955441 ("team: add peer notification")
Fixes: 492b200efdd20b8fcfd  ("team: add support for sending multicast rejoins")
Signed-off-by: Jiri Pirko 
Signed-off-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: avoid race condition in scheduling delayed work

2014-10-17T07:43:18+00:00

[ Upstream commit 47549650abd13d873fd2e5fc218db19e21031074 ]

When team_notify_peers and team_mcast_rejoin are called, they both reset
their respective .count_pending atomic variable. Then when the actual
worker function is executed, the variable is atomically decremented.
This pattern introduces a potential race condition where the
.count_pending rolls over and the worker function keeps rescheduling
until .count_pending decrements to zero again:

THREAD 1                           THREAD 2

========                           ========
team_notify_peers(teamX)
  atomic_set count_pending = 1
  schedule_delayed_work
                                   team_notify_peers(teamX)
                                   atomic_set count_pending = 1
team_notify_peers_work
  atomic_dec_and_test
    count_pending = 0
  (return)
                                   schedule_delayed_work
                                   team_notify_peers_work
                                   atomic_dec_and_test
                                     count_pending = -1
                                   schedule_delayed_work
                                   (repeat until count_pending = 0)

Instead of assigning a new value to .count_pending, use atomic_add to
tack-on the additional desired worker function invocations.

Signed-off-by: Joe Lawrence 
Acked-by: Jiri Pirko 
Fixes: fc423ff00df3a19554414ee ("team: add peer notification")
Fixes: 492b200efdd20b8fcfdac87 ("team: add support for sending multicast rejoins")
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: fix mtu setting

2014-06-23T08:28:00+00:00

[ Upstream commit 9d0d68faea6962d62dd501cd6e71ce5cc8ed262b ]

Now it is not possible to set mtu to team device which has a port
enslaved to it. The reason is that when team_change_mtu() calls
dev_set_mtu() for port device, notificator for NETDEV_PRECHANGEMTU
event is called and team_device_event() returns NOTIFY_BAD forbidding
the change. So fix this by returning NOTIFY_DONE here in case team is
changing mtu in team_change_mtu().

Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko 
Acked-by: Flavio Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: fix master carrier set when user linkup is enabled

2013-12-08T15:29:15+00:00

[ Upstream commit f5e0d34382e18f396d7673a84df8e3342bea7eb6 ]

When user linkup is enabled and user sets linkup of individual port,
we need to recompute linkup (carrier) of master interface so the change
is reflected. Fix this by calling __team_carrier_check() which does the
needed work.

Please apply to all stable kernels as well. Thanks.

Reported-by: Jan Tluka 
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: team: inherit addr_assign_type along with dev_addr

2013-09-04T00:57:49+00:00

A device inheriting a random or set address should reflect this in
its addr_assign_type.

Cc: Jiri Pirko 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller

team: cleanup netpoll clode

2013-07-26T22:24:32+00:00

This started out with fixing a sparse warning, then I realized that
the wrapper function team_netpoll_info could just be collapsed away
by rolling it into the enable code.

Signed-off-by: Stephen Hemminger 
Acked-by: Jiri Pirko 
Signed-off-by: David S. Miller

team: add support for sending multicast rejoins

2013-07-23T23:52:47+00:00

Similar to what is implemented in bonding. User is able to ask team
driver to send IGMP rejoins in case port is enabled or disabled. Using
previously introduced netdev notifier.

Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller

net: convert resend IGMP to notifier event

2013-07-23T23:52:47+00:00

Until now, bond_resend_igmp_join_requests() looks for vlans attached to
bonding device, bridge where bonding act as port manually. It does not
care of other scenarios, like stacked bonds or team device above. Make
this more generic and use netdev notifier to propagate the event to
upper devices and to actually call ip_mc_rejoin_groups().

Signed-off-by: Jiri Pirko 
Acked-by: Veaceslav Falico 
Signed-off-by: David S. Miller