diff options
| author | Jiri Pirko <jiri@resnulli.us> | 2015-01-14 18:15:30 +0100 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2015-01-14 16:53:57 -0500 |
| commit | b0d11b42785b70e19bc6a3122eead3f7969a7589 (patch) | |
| tree | 06ca980eca49523be349e19fdbd50c2e090d7f6f /include/rdma/ib_cache.h | |
| parent | 1ba398041f5b5a15456ea20a9ba3ff80b6a4e7d1 (diff) | |
| download | op-kernel-dev-b0d11b42785b70e19bc6a3122eead3f7969a7589.zip op-kernel-dev-b0d11b42785b70e19bc6a3122eead3f7969a7589.tar.gz | |
team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin
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 <jiri@resnulli.us>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/rdma/ib_cache.h')
0 files changed, 0 insertions, 0 deletions
