“bb8646d8340fa7c1b66a037428e39f85f8738f0a”上不存在“arch/sparc/mm/tsb.c”
  1. 18 10月, 2014 1 次提交
    • J
      tipc: fix bug in bundled buffer reception · 643566d4
      Jon Paul Maloy 提交于
      In commit ec8a2e56 ("tipc: same receive
      code path for connection protocol and data messages") we omitted the
      the possiblilty that an arriving message extracted from a bundle buffer
      may be a multicast message. Such messages need to be to be delivered to
      the socket via a separate function, tipc_sk_mcast_rcv(). As a result,
      small multicast messages arriving as members of a bundle buffer will be
      silently dropped.
      
      This commit corrects the error by considering this case in the function
      tipc_link_bundle_rcv().
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      643566d4
  2. 08 10月, 2014 1 次提交
    • J
      tipc: fix bug in multicast congestion handling · 908344cd
      Jon Maloy 提交于
      One aim of commit 50100a5e ("tipc:
      use pseudo message to wake up sockets after link congestion") was
      to handle link congestion abatement in a uniform way for both unicast
      and multicast transmit. However, the latter doesn't work correctly,
      and has been broken since the referenced commit was applied.
      
      If a user now sends a burst of multicast messages that is big
      enough to cause broadcast link congestion, it will be put to sleep,
      and not be waked up when the congestion abates as it should be.
      
      This has two reasons. First, the flag that is used, TIPC_WAKEUP_USERS,
      is set correctly, but in the wrong field. Instead of setting it in the
      'action_flags' field of the arrival node struct, it is by mistake set
      in the dummy node struct that is owned by the broadcast link, where it
      will never tested for. Second, we cannot use the same flag for waking
      up unicast and multicast users, since the function tipc_node_unlock()
      needs to pick the wakeup pseudo messages to deliver from different
      queues. It must hence be able to distinguish between the two cases.
      
      This commit solves this problem by adding a new flag
      TIPC_WAKEUP_BCAST_USERS, and a new function tipc_bclink_wakeup_user().
      The latter is to be called by tipc_node_unlock() when the named flag,
      now set in the correct field, is encountered.
      
      v2: using explicit 'unsigned int' declaration instead of 'uint', as
      per comment from David Miller.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      908344cd
  3. 11 9月, 2014 1 次提交
  4. 02 9月, 2014 2 次提交
    • E
      tipc: add name distributor resiliency queue · a5325ae5
      Erik Hugne 提交于
      TIPC name table updates are distributed asynchronously in a cluster,
      entailing a risk of certain race conditions. E.g., if two nodes
      simultaneously issue conflicting (overlapping) publications, this may
      not be detected until both publications have reached a third node, in
      which case one of the publications will be silently dropped on that
      node. Hence, we end up with an inconsistent name table.
      
      In most cases this conflict is just a temporary race, e.g., one
      node is issuing a publication under the assumption that a previous,
      conflicting, publication has already been withdrawn by the other node.
      However, because of the (rtt related) distributed update delay, this
      may not yet hold true on all nodes. The symptom of this failure is a
      syslog message: "tipc: Cannot publish {%u,%u,%u}, overlap error".
      
      In this commit we add a resiliency queue at the receiving end of
      the name table distributor. When insertion of an arriving publication
      fails, we retain it in this queue for a short amount of time, assuming
      that another update will arrive very soon and clear the conflict. If so
      happens, we insert the publication, otherwise we drop it.
      
      The (configurable) retention value defaults to 2000 ms. Knowing from
      experience that the situation described above is extremely rare, there
      is no risk that the queue will accumulate any large number of items.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5325ae5
    • E
      tipc: refactor name table updates out of named packet receive routine · f4ad8a4b
      Erik Hugne 提交于
      We need to perform the same actions when processing deferred name
      table updates, so this functionality is moved to a separate
      function.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4ad8a4b
  5. 30 8月, 2014 1 次提交
  6. 24 8月, 2014 15 次提交
  7. 20 8月, 2014 1 次提交
  8. 17 8月, 2014 1 次提交
  9. 30 7月, 2014 1 次提交
  10. 29 7月, 2014 1 次提交
    • J
      tipc: make tipc_buf_append() more robust · 13e9b997
      Jon Paul Maloy 提交于
      As per comment from David Miller, we try to make the buffer reassembly
      function more resilient to user errors than it is today.
      
      - We check that the "*buf" parameter always is set, since this is
        mandatory input.
      
      - We ensure that *buf->next always is set to NULL before linking in
        the buffer, instead of relying of the caller to have done this.
      
      - We ensure that the "tail" pointer in the head buffer's control
        block is initialized to NULL when the first fragment arrives.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13e9b997
  11. 21 7月, 2014 1 次提交
  12. 17 7月, 2014 7 次提交
  13. 16 7月, 2014 1 次提交
  14. 12 7月, 2014 1 次提交
    • J
      tipc: clear 'next'-pointer of message fragments before reassembly · 99941754
      Jon Paul Maloy 提交于
      If the 'next' pointer of the last fragment buffer in a message is not
      zeroed before reassembly, we risk ending up with a corrupt message,
      since the reassembly function itself isn't doing this.
      
      Currently, when a buffer is retrieved from the deferred queue of the
      broadcast link, the next pointer is not cleared, with the result as
      described above.
      
      This commit corrects this, and thereby fixes a bug that may occur when
      long broadcast messages are transmitted across dual interfaces. The bug
      has been present since 40ba3cdf ("tipc:
      message reassembly using fragment chain")
      
      This commit should be applied to both net and net-next.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99941754
  15. 09 7月, 2014 2 次提交
  16. 08 7月, 2014 2 次提交
  17. 28 6月, 2014 1 次提交
    • J
      tipc: simplify connection congestion handling · 60120526
      Jon Paul Maloy 提交于
      As a consequence of the recently introduced serialized access
      to the socket in commit 8d94168a761819d10252bab1f8de6d7b202c3baa
      ("tipc: same receive code path for connection protocol and data
      messages") we can make a number of simplifications in the
      detection and handling of connection congestion situations.
      
      - We don't need to keep two counters, one for sent messages and one
        for acked messages. There is no longer any risk for races between
        acknowledge messages arriving in BH and data message sending
        running in user context. So we merge this into one counter,
        'sent_unacked', which is incremented at sending and subtracted
        from at acknowledge reception.
      
      - We don't need to set the 'congested' field in tipc_port to
        true before we sent the message, and clear it when sending
        is successful. (As a matter of fact, it was never necessary;
        the field was set in link_schedule_port() before any wakeup
        could arrive anyway.)
      
      - We keep the conditions for link congestion and connection connection
        congestion separated. There would otherwise be a risk that an arriving
        acknowledge message may wake up a user sleeping because of link
        congestion.
      
      - We can simplify reception of acknowledge messages.
      
      We also make some cosmetic/structural changes:
      
      - We rename the 'congested' field to the more correct 'link_cong´.
      
      - We rename 'conn_unacked' to 'rcv_unacked'
      
      - We move the above mentioned fields from struct tipc_port to
        struct tipc_sock.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60120526