diff options
| author | Joe Lawrence <Joe.Lawrence@stratus.com> | 2014-10-03 09:58:34 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-10-15 12:05:30 +0200 |
| commit | 1f8649d07512f88a2f9a0e297e4616834e162857 (patch) | |
| tree | 8a250efaa7186e7566e87c9e93b806cdf00b500b /include/linux/kdebug.h | |
| parent | d24e8812d4fd0ef52abcb66df2bc23d310018caa (diff) | |
team: avoid race condition in scheduling delayed work
[ 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 <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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include/linux/kdebug.h')
0 files changed, 0 insertions, 0 deletions
