1. 07 2月, 2012 4 次提交
    • A
      tipc: Ensure broadcast link re-acquires node after link failure · 93499313
      Allan Stephens 提交于
      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: NAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      93499313
    • A
      tipc: Prevent broadcast link stalling in dual LAN environments · 4d75313c
      Allan Stephens 提交于
      Ensure that sequence number information about incoming broadcast link
      messages is initialized only by the activation of the first link to a
      given cluster node.  Previously, a race condition allowed reset and/or
      activation messages for a second link to re-initialize this sequence
      number information with obsolete values. This could trigger TIPC to
      request the retransmission of previously acknowledged broadcast link
      messages from that node, resulting in broadcast link processing becoming
      stalled if the node had already released one or more of those messages
      and was unable to perform the required retransmission.
      
      Thanks to Laser <gotolaser@gmail.com> for identifying this problem
      and assisting in the development of this fix.
      Signed-off-by: NAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      4d75313c
    • A
      tipc: Prevent transmission of outdated link protocol messages · 92d2c905
      Allan Stephens 提交于
      Ensures that a link endpoint discards any previously deferred link
      protocol message whenever it attempts to send a new one.
      
      Previously, it was possible for a link protocol message that was unsent
      due to congestion to be transmitted after newer protocol messages had
      been sent. The stale link protocol message might then cause the receiving
      link endpoint to malfunction because of its outdated conent.
      
      Thanks to Osamu Kaminuma [okaminum@avaya.com] for diagnosing the problem
      and contributing a prototype patch.
      Signed-off-by: NAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      92d2c905
    • A
      tipc: improve the link deferred queue insertion algorithm · 8809b255
      Allan Stephens 提交于
      Re-code the algorithm for inserting an out-of-sequence message into
      a unicast or broadcast link's deferred message queue.  It remains
      functionally equivalent but should be easier to understand/maintain.
      Signed-off-by: NAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8809b255
  2. 06 2月, 2012 9 次提交
  3. 05 2月, 2012 27 次提交