tipc: Ensure broadcast link re-acquires node after link failure
authorAllan Stephens <allan.stephens@windriver.com>
Tue, 25 Oct 2011 19:14:46 +0000 (15:14 -0400)
committerPaul Gortmaker <paul.gortmaker@windriver.com>
Mon, 6 Feb 2012 21:59:16 +0000 (16:59 -0500)
commit934993137199ffb56fef50664f87e71cdb3471b0
treeeda9ba8ab9f8bed085ff108b38765b72aa8e4e50
parent4d75313ce9b832efc4efb487f080b5ed72beae2c
tipc: Ensure broadcast link re-acquires node after link failure

Fix a bug that can prevent TIPC from sending broadcast messages to a node
if contact with the node is lost and then regained. The problem occurs if
the broadcast link first clears the flag indicating the node is part of the
link's distribution set (when it loses contact with the node), and later
fails to restore the flag (when contact is regained); restoration fails
if contact with the node is regained by implicit unicast link activation
triggered by the arrival of a data message, rather than explicitly by the
arrival of a link activation message.

The broadcast link now uses separate fields to track whether a node is
theoretically capable of receiving broadcast messages versus whether it is
actually part of the link's distribution set. The former member is updated
by the receipt of link protocol messages, which can occur at any time; the
latter member is updated only when contact with the node is gained or lost.
This change also permits the simplification of several conditional
expressions since the broadcast link's "supported" field can now only be
set if there are working links to the associated node.

Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
net/tipc/link.c
net/tipc/node.c
net/tipc/node.h