summaryrefslogtreecommitdiff
path: root/mm/zbud.c
diff options
context:
space:
mode:
authorJon Paul Maloy <jon.maloy@ericsson.com>2015-03-25 16:07:26 (GMT)
committerDavid S. Miller <davem@davemloft.net>2015-03-25 18:05:56 (GMT)
commit8b4ed8634f8b3f9aacfc42b4a872d30c36b9e255 (patch)
treea53fedc6a39f617600e4aebf4957d67195d7a37a /mm/zbud.c
parent3127a0200d4a46cf279bb388cc0f71827cd60699 (diff)
downloadlinux-8b4ed8634f8b3f9aacfc42b4a872d30c36b9e255.tar.xz
tipc: eliminate race condition at dual link establishment
Despite recent improvements, the establishment of dual parallel links still has a small glitch where messages can bypass each other. When the second link in a dual-link configuration is established, part of the first link's traffic will be steered over to the new link. Although we do have a mechanism to ensure that packets sent before and after the establishment of the new link arrive in sequence to the destination node, this is not enough. The arriving messages will still be delivered upwards in different threads, something entailing a risk of message disordering during the transition phase. To fix this, we introduce a synchronization mechanism between the two parallel links, so that traffic arriving on the new link cannot be added to its input queue until we are guaranteed that all pre-establishment messages have been delivered on the old, parallel link. This problem seems to always have been around, but its occurrence is so rare that it has not been noticed until recent intensive testing. Reviewed-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/zbud.c')
0 files changed, 0 insertions, 0 deletions