1. 06 May, 2013 2 commits
  2. 06 Dec, 2012 1 commit
    • Erik Hugne's avatar
      tipc: remove obsolete flush of stale reassembly buffer · c0084138
      Erik Hugne authored
      
      
      Each link instance has a periodic job checking if there is a stale
      ongoing message reassembly associated to the link. If no new
      fragment has been received during the last 4*[link_tolerance] period,
      it is assumed the missing fragment will never arrive. As a consequence,
      the reassembly buffer is discarded, and a gap in the message sequence
      occurs.
      
      This assumption is wrong. After we abandoned our ambition to develop
      packet routing for multi-cluster networks, only single-hop packet
      transfer remains as an option. For those, all packets are guaranteed
      to be delivered in sequence to the defragmentation layer. Any failure
      to achieve sequenced delivery will eventually lead to link reset, and
      the reassembly buffer will be flushed anyway.
      
      So we just remove this periodic check, which is now obsolete.
      
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      [PG: also delete get/inc_timer count, since they are now unused]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      c0084138
  3. 22 Nov, 2012 4 commits
    • Jon Maloy's avatar
      tipc: introduce message to synchronize broadcast link · c64f7a6a
      Jon Maloy authored
      
      
      Upon establishing a first link between two nodes, there is
      currently a risk that the two endpoints will disagree on exactly
      which sequence number reception and acknowleding of broadcast
      packets should start.
      
      The following scenarios may happen:
      
      1: Node A sends an ACTIVATE message to B, telling it to start acking
         packets from sequence number N.
      2: Node A sends out broadcast N, but does not expect an acknowledge
         from B, since B is not yet in its broadcast receiver's list.
      3: Node A receives ACK for N from all nodes except B, and releases
         packet N.
      4: Node B receives the ACTIVATE, activates its link endpoint, and
         stores the value N as sequence number of first expected packet.
      5: Node B sends a NAME_DISTR message to A.
      6: Node A receives the NAME_DISTR message, and activates its endpoint.
         At this moment B is added to A's broadcast receiver's set.
         Node A also sets sequence number 0 as the first broadcast packet
         to be received from B.
      7: Node A sends broadcast N+1.
      8: B receives N+1, determines there is a gap in the sequence, since
         it is expecting N, and sends a NACK for N back to A.
      9: Node A has already released N, so no retransmission is possible.
         The broadcast link in direction A->B is stale.
      
      In addition to, or instead of, 7-9 above, the following may happen:
      
      10: Node B sends broadcast M > 0 to A.
      11: Node A receives M, falsely decides there must be a gap, since
          it is expecting packet 0, and asks for retransmission of packets
          [0,M-1].
      12: Node B has already released these packets, so the broadcast
          link is stale in direction B->A.
      
      We solve this problem by introducing a new unicast message type,
      BCAST_PROTOCOL/STATE, to convey the sequence number of the next
      sent broadcast packet to the other endpoint, at exactly the moment
      that endpoint is added to the own node's broadcast receivers list,
      and before any other unicast messages are permitted to be sent.
      
      Furthermore, we don't allow any node to start receiving and
      processing broadcast packets until this new synchronization
      message has been received.
      
      To maintain backwards compatibility, we still open up for
      broadcast reception if we receive a NAME_DISTR message without
      any preceding broadcast sync message. In this case, we must
      assume that the other end has an older code version, and will
      never send out the new synchronization message. Hence, for mixed
      old and new nodes, the issue arising in 7-12 of the above may
      happen with the same probability as before.
      
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      c64f7a6a
    • Ying Xue's avatar
      tipc: rename supported flag to recv_permitted · 389dd9bc
      Ying Xue authored
      
      
      Rename the "supported" flag in bclink structure to "recv_permitted"
      to better reflect what it is used for. When this flag is set for a
      given node, we are permitted to receive and acknowledge broadcast
      messages from that node.  Convert it to a bool at the same time,
      since it is not used to store any numerical values.
      
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      389dd9bc
    • Ying Xue's avatar
      tipc: remove supportable flag from bclink structure · 818f4da5
      Ying Xue authored
      
      
      The "supportable" flag in bclink structure is a compatibility flag
      indicating whether a peer node is capable of receiving TIPC broadcast
      messages. However, all TIPC versions since tipc-1.5, and after the
      inclusion in the upstream Linux kernel in 2006, support this capability.
      It is highly unlikely that anybody is still using such an old
      version of TIPC, let alone that they want to mix it with TIPC-2.0
      nodes. Therefore, we now remove the "supportable" flag.
      
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      818f4da5
    • Ying Xue's avatar
      tipc: remove the bearer congestion mechanism · 3c294cb3
      Ying Xue authored
      
      
      Currently at the TIPC bearer layer there is the following congestion
      mechanism:
      
      Once sending packets has failed via that bearer, the bearer will be
      flagged as being in congested state at once. During bearer congestion,
      all packets arriving at link will be queued on the link's outgoing
      buffer.  When we detect that the state of bearer congestion has
      relaxed (e.g. some packets are received from the bearer) we will try
      our best to push all packets in the link's outgoing buffer until the
      buffer is empty, or until the bearer is congested again.
      
      However, in fact the TIPC bearer never receives any feedback from the
      device layer whether a send was successful or not, so it must always
      assume it was successful. Therefore, the bearer congestion mechanism
      as it exists currently is of no value.
      
      But the bearer blocking state is still useful for us. For example,
      when the physical media goes down/up, we need to change the state of
      the links bound to the bearer.  So the code maintaing the state
      information is not removed.
      
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      3c294cb3
  4. 20 Aug, 2012 1 commit
  5. 13 Jul, 2012 4 commits
    • Erik Hugne's avatar
      tipc: phase out most of the struct print_buf usage · dc1aed37
      Erik Hugne authored
      
      
      The tipc_printf is renamed to tipc_snprintf, as the new name
      describes more what the function actually does.  It is also
      changed to take a buffer and length parameter and return
      number of characters written to the buffer.  All callers of
      this function that used to pass a print_buf are updated.
      
      Final removal of the struct print_buf itself will be done
      synchronously with the pending removal of the deprecated
      logging code that also was using it.
      
      Functions that build up a response message with a list of
      ports, nametable contents etc. are changed to return the number
      of characters written to the output buffer. This information
      was previously hidden in a field of the print_buf struct, and
      the number of chars written was fetched with a call to
      tipc_printbuf_validate.  This function is removed since it
      is no longer referenced nor needed.
      
      A generic max size ULTRA_STRING_MAX_LEN is defined, named
      in keeping with the existing TIPC_TLV_ULTRA_STRING, and the
      various definitions in port, link and nametable code that
      largely duplicated this information are removed.  This means
      that amount of link statistics that can be returned is now
      increased from 2k to 32k.
      
      The buffer overflow check is now done just before the reply
      message is passed over netlink or TIPC to a remote node and
      the message indicating a truncated buffer is changed to a less
      dramatic one (less CAPS), placed at the end of the message.
      
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      dc1aed37
    • Paul Gortmaker's avatar
      tipc: simplify link_print by divorcing it from using tipc_printf · 5deedde9
      Paul Gortmaker authored
      
      
      To pave the way for a pending cleanup of tipc_printf, and
      removal of struct print_buf entirely, we make that task simpler
      by converting link_print to issue its messages with standard
      printk infrastructure.  [Original idea separated from a larger
      patch from Erik Hugne <erik.hugne@ericsson.com>]
      
      Cc: Erik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      5deedde9
    • Erik Hugne's avatar
      tipc: remove TIPC packet debugging functions and macros · 568fc588
      Erik Hugne authored
      
      
      The link queue traces and packet level debug functions served
      a purpose during early development, but are now redundant
      since there are other, more capable tools available for
      debugging at the packet level.
      
      The TIPC_DEBUG Kconfig option is removed since it does not
      provide any extra debugging features anymore.
      
      This gets rid of a lot of tipc_printf usages, which will
      make the pending cleanup work of that function easier.
      
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      568fc588
    • Erik Hugne's avatar
      tipc: use standard printk shortcut macros (pr_err etc.) · 2cf8aa19
      Erik Hugne authored
      
      
      All messages should go directly to the kernel log.  The TIPC
      specific error, warning, info and debug trace macro's are
      removed and all references replaced with pr_err, pr_warn,
      pr_info and pr_debug.
      
      Commonly used sub-strings are explicitly declared as a const
      char to reduce .text size.
      
      Note that this means the debug messages (changed to pr_debug),
      are now enabled through dynamic debugging, instead of a TIPC
      specific Kconfig option (TIPC_DEBUG).  The latter will be
      phased out completely
      
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      [PG: use pr_fmt as suggested by Joe Perches <joe@perches.com>]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      2cf8aa19
  6. 11 Jul, 2012 1 commit
  7. 30 Apr, 2012 1 commit
    • Paul Gortmaker's avatar
      tipc: compress out gratuitous extra carriage returns · 617d3c7a
      Paul Gortmaker authored
      
      
      Some of the comment blocks are floating in limbo between two
      functions, or between blocks of code.  Delete the extra line
      feeds between any comment and its associated following block
      of code, to be consistent with the majority of the rest of
      the kernel.  Also delete trailing newlines at EOF and fix
      a couple trivial typos in existing comments.
      
      This is a 100% cosmetic change with no runtime impact.  We get
      rid of over 500 lines of non-code, and being blank line deletes,
      they won't even show up as noise in git blame.
      
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      617d3c7a
  8. 15 Apr, 2012 1 commit
  9. 29 Feb, 2012 1 commit
  10. 24 Feb, 2012 2 commits
  11. 06 Feb, 2012 7 commits
    • Allan Stephens's avatar
      tipc: Prevent loss of fragmented messages over unicast links · b76b27ca
      Allan Stephens authored
      
      
      Modifies unicast link endpoint logic so an incoming fragmented message
      is not lost if reassembly cannot begin because there is no buffer big
      enough to hold the entire reassembled message. The link endpoint now
      ignores the first fragment completely, which causes the sending node to
      retransmit the first fragment so that reassembly can be re-attempted.
      
      Previously, the sender would have had no reason to retransmit the 1st
      fragment, so we would never have a chance to re-try the allocation.
      
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      b76b27ca
    • Allan Stephens's avatar
      tipc: Major redesign of broadcast link ACK/NACK algorithms · 7a54d4a9
      Allan Stephens authored
      
      
      Completely redesigns broadcast link ACK and NACK mechanisms to prevent
      spurious retransmit requests in dual LAN networks, and to prevent the
      broadcast link from stalling due to the failure of a receiving node to
      acknowledge receiving a broadcast message or request its retransmission.
      
      Note: These changes only impact the timing of when ACK and NACK messages
      are sent, and not the basic broadcast link protocol itself, so inter-
      operability with nodes using the "classic" algorithms is maintained.
      
      The revised algorithms are as follows:
      
      1) An explicit ACK message is still sent after receiving 16 in-sequence
      messages, and implicit ACK information continues to be carried in other
      unicast link message headers (including link state messages).  However,
      the timing of explicit ACKs is now based on the receiving node's absolute
      network address rather than its relative network address to ensure that
      the failure of another node does not delay the ACK beyond its 16 message
      target.
      
      2) A NACK message is now typically sent only when a message gap persists
      for two consecutive incoming link state messages; this ensures that a
      suspected gap is not confirmed until both LANs in a dual LAN network have
      had an opportunity to deliver the message, thereby preventing spurious NACKs.
      A NACK message can also be generated by the arrival of a single link state
      message, if the deferred queue is so big that the current message gap
      cannot be the result of "normal" mis-ordering due to the use of dual LANs
      (or one LAN using a bonded interface). Since link state messages typically
      arrive at different nodes at different times the problem of multiple nodes
      issuing identical NACKs simultaneously is inherently avoided.
      
      3) Nodes continue to "peek" at NACK messages sent by other nodes. If
      another node requests retransmission of a message gap suspected (but not
      yet confirmed) by the peeking node, the peeking node forgets about the
      gap and does not generate a duplicate retransmit request. (If the peeking
      node subsequently fails to receive the lost message, later link state
      messages will cause it to rediscover and confirm the gap and send another
      NACK.)
      
      4) Message gap "equality" is now determined by the start of the gap only.
      This is sufficient to deal with the most common cases of message loss,
      and eliminates the need for complex end of gap computations.
      
      5) A peeking node no longer tries to determine whether it should send a
      complementary NACK, since the most common cases of message loss don't
      require it to be sent. Consequently, the node no longer examines the
      "broadcast tag" field of a NACK message when peeking.
      
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      7a54d4a9
    • Allan Stephens's avatar
      tipc: Fix problem with broadcast link synchronization between nodes · 47361c87
      Allan Stephens authored
      
      
      Corrects a problem in which a link endpoint that activates as the
      result of receiving a RESET/STATE sequence of link protocol messages
      fails to properly record the broadcast link status information about
      the node to which it is now communicating with. (The problem does
      not occur with the more common RESET/ACTIVATE sequence of messages.)
      The fix ensures that the broadcast link status info is updated after
      the RESET message resets the link endpoint, rather than before, thereby
      preventing new information from being overwritten by the reset operation.
      
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      47361c87
    • Allan Stephens's avatar
      tipc: Ensure broadcast link re-acquires node after link failure · 93499313
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      93499313
    • Allan Stephens's avatar
      tipc: Prevent broadcast link stalling in dual LAN environments · 4d75313c
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4d75313c
    • Allan Stephens's avatar
      tipc: Prevent transmission of outdated link protocol messages · 92d2c905
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      92d2c905
    • Allan Stephens's avatar
      tipc: improve the link deferred queue insertion algorithm · 8809b255
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      8809b255
  12. 30 Dec, 2011 2 commits
  13. 27 Dec, 2011 3 commits
  14. 18 Sep, 2011 3 commits
    • Ying Xue's avatar
      tipc: Remove unused link event tracking code · 94362c7e
      Ying Xue authored
      
      
      Elimintes prototype link event tracking functionality that has never
      been fleshed out and doesn't do anything useful at the current time.
      
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      94362c7e
    • Allan Stephens's avatar
      tipc: Enhance sending of bulk name table messages · 9aa88c2a
      Allan Stephens authored
      
      
      Modifies the initial transfer of name table entries to a new neighboring
      node so that the messages are enqueued as a unit, rather than individually.
      
      The revised algorithm now locates the link carrying the message only once,
      and eliminates unnecessary checks for link congestion, message fragmentation,
      and message bundling that are not required when sending these messages.
      
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      9aa88c2a
    • Allan Stephens's avatar
      tipc: Ensure both nodes recognize loss of contact between them · b4b56102
      Allan Stephens authored
      
      
      Enhances TIPC to ensure that a node that loses contact with a
      neighboring node does not allow contact to be re-established until
      it sees that its peer has also recognized the loss of contact.
      
      Previously, nodes that were connected by two or more links could
      encounter a situation in which node A would lose contact with node B
      on all of its links, purge its name table of names published by B,
      and then fail to repopulate those names once contact with B was restored.
      This would happen because B was able to re-establish one or more links
      so quickly that it never reached a point where it had no links to A --
      meaning that B never saw a loss of contact with A, and consequently
      didn't re-publish its names to A.
      
      This problem is now prevented by enhancing the cleanup done by TIPC
      following a loss of contact with a neighboring node to ensure that
      node A ignores all messages sent by B until it receives a LINK_PROTOCOL
      message that indicates B has lost contact with A, thereby preventing
      the (re)establishment of links between the nodes. The loss of contact
      is recognized when a RESET or ACTIVATE message is received that has
      a "redundant link exists" field of 0, indicating that B's sending link
      endpoint is in a reset state and that B has no other working links.
      
      Additionally, TIPC now suppresses the sending of (most) link protocol
      messages to a neighboring node while it is cleaning up after an earlier
      loss of contact with that node. This stops the peer node from prematurely
      activating its link endpoint, which would prevent TIPC from later
      activating its own end. TIPC still allows outgoing RESET messages to
      occur during cleanup, to avoid problems if its own node recognizes
      the loss of contact first and tries to notify the peer of the situation.
      
      Finally, TIPC now recognizes an impending loss of contact with a peer node
      as soon as it receives a RESET message on a working link that is the
      peer's only link to the node, and ensures that the link protocol
      suppression mentioned above goes into effect right away -- that is,
      even before its own link endpoints have failed. This is necessary to
      ensure correct operation when there are redundant links between the nodes,
      since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
      on its first link and only begin suppressing when a RESET on its second
      link was received, instead of initiating suppression with the first RESET
      message as it needs to.
      
      Note: The reworked cleanup code also eliminates a check that prevented
      a link endpoint's discovery object from responding to incoming messages
      while stale name table entries are being purged. This check is now
      unnecessary and would have slowed down re-establishment of communication
      between the nodes in some situations.
      
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      b4b56102
  15. 01 Sep, 2011 5 commits
  16. 24 Jun, 2011 2 commits