diff options
| author | Joe Lawrence <Joe.Lawrence@stratus.com> | 2014-10-03 17:58:34 +0400 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2014-10-05 04:50:50 +0400 |
| commit | 47549650abd13d873fd2e5fc218db19e21031074 (patch) | |
| tree | 28e33cbf979472878236ca81cd86771ae7ab9fa1 /drivers/net/hyperv | |
| parent | 34a419d4e20d6be5e0c4a3b27f6eface366a4836 (diff) | |
| download | linux-47549650abd13d873fd2e5fc218db19e21031074.tar.xz | |
team: avoid race condition in scheduling delayed work
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 <joe.lawrence@stratus.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Fixes: fc423ff00df3a19554414ee ("team: add peer notification")
Fixes: 492b200efdd20b8fcfdac87 ("team: add support for sending multicast rejoins")
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/hyperv')
0 files changed, 0 insertions, 0 deletions