1. 06 2月, 2015 2 次提交
    • J
      tipc: resolve race problem at unicast message reception · c637c103
      Jon Paul Maloy 提交于
      TIPC handles message cardinality and sequencing at the link layer,
      before passing messages upwards to the destination sockets. During the
      upcall from link to socket no locks are held. It is therefore possible,
      and we see it happen occasionally, that messages arriving in different
      threads and delivered in sequence still bypass each other before they
      reach the destination socket. This must not happen, since it violates
      the sequentiality guarantee.
      
      We solve this by adding a new input buffer queue to the link structure.
      Arriving messages are added safely to the tail of that queue by the
      link, while the head of the queue is consumed, also safely, by the
      receiving socket. Sequentiality is secured per socket by only allowing
      buffers to be dequeued inside the socket lock. Since there may be multiple
      simultaneous readers of the queue, we use a 'filter' parameter to reduce
      the risk that they peek the same buffer from the queue, hence also
      reducing the risk of contention on the receiving socket locks.
      
      This solves the sequentiality problem, and seems to cause no measurable
      performance degradation.
      
      A nice side effect of this change is that lock handling in the functions
      tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
      will enable future simplifications of those functions.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c637c103
    • J
      tipc: reduce usage of context info in socket and link · c5898636
      Jon Paul Maloy 提交于
      The most common usage of namespace information is when we fetch the
      own node addess from the net structure. This leads to a lot of
      passing around of a parameter of type 'struct net *' between
      functions just to make them able to obtain this address.
      
      However, in many cases this is unnecessary. The own node address
      is readily available as a member of both struct tipc_sock and
      tipc_link, and can be fetched from there instead.
      The fact that the vast majority of functions in socket.c and link.c
      anyway are maintaining a pointer to their respective base structures
      makes this option even more compelling.
      
      In this commit, we introduce the inline functions tsk_own_node()
      and link_own_node() to make it easy for functions to fetch the node
      address from those structs instead of having to pass along and
      dereference the namespace struct.
      
      In particular, we make calls to the msg_xx() functions in msg.{h,c}
      context independent by directly passing them the own node address
      as parameter when needed. Those functions should be regarded as
      leaves in the code dependency tree, and it is hence desirable to
      keep them namspace unaware.
      
      Apart from a potential positive effect on cache behavior, these
      changes make it easier to introduce the changes that will follow
      later in this series.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5898636
  2. 13 1月, 2015 7 次提交
    • Y
      tipc: make tipc node address support net namespace · 34747539
      Ying Xue 提交于
      If net namespace is supported in tipc, each namespace will be treated
      as a separate tipc node. Therefore, every namespace must own its
      private tipc node address. This means the "tipc_own_addr" global
      variable of node address must be moved to tipc_net structure to
      satisfy the requirement. It's turned out that users also can assign
      node address for every namespace.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Tested-by: NTero Aho <Tero.Aho@coriant.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34747539
    • Y
      tipc: make tipc broadcast link support net namespace · 1da46568
      Ying Xue 提交于
      TIPC broadcast link is statically established and its relevant states
      are maintained with the global variables: "bcbearer", "bclink" and
      "bcl". Allowing different namespace to own different broadcast link
      instances, these variables must be moved to tipc_net structure and
      broadcast link instances would be allocated and initialized when
      namespace is created.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Tested-by: NTero Aho <Tero.Aho@coriant.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1da46568
    • Y
      tipc: make bearer list support net namespace · 7f9f95d9
      Ying Xue 提交于
      Bearer list defined as a global variable is used to store bearer
      instances. When tipc supports net namespace, bearers created in
      one namespace must be isolated with others allocated in other
      namespaces, which requires us that the bearer list(bearer_list)
      must be moved to tipc_net structure. As a result, a net namespace
      pointer has to be passed to functions which access the bearer list.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Tested-by: NTero Aho <Tero.Aho@coriant.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f9f95d9
    • Y
      tipc: make tipc node table aware of net namespace · f2f9800d
      Ying Xue 提交于
      Global variables associated with node table are below:
      - node table list (node_htable)
      - node hash table list (tipc_node_list)
      - node table lock (node_list_lock)
      - node number counter (tipc_num_nodes)
      - node link number counter (tipc_num_links)
      
      To make node table support namespace, above global variables must be
      moved to tipc_net structure in order to keep secret for different
      namespaces. As a consequence, these variables are allocated and
      initialized when namespace is created, and deallocated when namespace
      is destroyed. After the change, functions associated with these
      variables have to utilize a namespace pointer to access them. So
      adding namespace pointer as a parameter of these functions is the
      major change made in the commit.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Tested-by: NTero Aho <Tero.Aho@coriant.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2f9800d
    • Y
      tipc: involve namespace infrastructure · c93d3baa
      Ying Xue 提交于
      Involve namespace infrastructure, make the "tipc_net_id" global
      variable aware of per namespace, and rename it to "net_id". In
      order that the conversion can be successfully done, an instance
      of networking namespace must be passed to relevant functions,
      allowing them to access the "net_id" variable of per namespace.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Tested-by: NTero Aho <Tero.Aho@coriant.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c93d3baa
    • J
      tipc: fix bug in broadcast retransmit code · 703068ee
      Jon Maloy 提交于
      In commit 58dc55f2 ("tipc: use generic
      SKB list APIs to manage link transmission queue") we replace all list
      traversal loops with the macros skb_queue_walk() or
      skb_queue_walk_safe(). While the previous loops were based on the
      assumption that the list was NULL-terminated, the standard macros
      stop when the iterator reaches the list head, which is non-NULL.
      
      In the function bclink_retransmit_pkt() this macro replacement has
      lead to a bug. When we receive a BCAST STATE_MSG we unconditionally
      call the function bclink_retransmit_pkt(), whether there really is
      anything to retransmit or not, assuming that the sequence number
      comparisons will lead to the correct behavior. However, if the
      transmission queue is empty, or if there are no eligible buffers in
      the transmission queue, we will by mistake pass the list head pointer
      to the function tipc_link_retransmit(). Since the list head is not a
      valid sk_buff, this leads to a crash.
      
      In this commit we fix this by only calling tipc_link_retransmit()
      if we actually found eligible buffers in the transmission queue.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      703068ee
    • J
      tipc: fix bug in broadcast retransmit code · 16416779
      Jon Paul Maloy 提交于
      In commit 58dc55f2 ("tipc: use generic
      SKB list APIs to manage link transmission queue") we replace all list
      traversal loops with the macros skb_queue_walk() or
      skb_queue_walk_safe(). While the previous loops were based on the
      assumption that the list was NULL-terminated, the standard macros
      stop when the iterator reaches the list head, which is non-NULL.
      
      In the function bclink_retransmit_pkt() this macro replacement has
      lead to a bug. When we receive a BCAST STATE_MSG we unconditionally
      call the function bclink_retransmit_pkt(), whether there really is
      anything to retransmit or not, assuming that the sequence number
      comparisons will lead to the correct behavior. However, if the
      transmission queue is empty, or if there are no eligible buffers in
      the transmission queue, we will by mistake pass the list head pointer
      to the function tipc_link_retransmit(). Since the list head is not a
      valid sk_buff, this leads to a crash.
      
      In this commit we fix this by only calling tipc_link_retransmit()
      if we actually found eligible buffers in the transmission queue.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16416779
  3. 10 12月, 2014 1 次提交
  4. 27 11月, 2014 4 次提交
  5. 25 11月, 2014 1 次提交
  6. 22 11月, 2014 1 次提交
    • R
      tipc: add link get/dump to new netlink api · 7be57fc6
      Richard Alpe 提交于
      Add TIPC_NL_LINK_GET command to the new tipc netlink API.
      
      This command supports dumping all information about all links
      (including the broadcast link) or getting all information about a
      specific link (not the broadcast link).
      
      The information about a link includes name, transmission info,
      properties and link statistics.
      
      As the tipc broadcast link is special we unfortunately have to treat
      it specially. It is a deliberate decision not to abstract the
      broadcast link on this (API) level.
      
      Netlink logical layout of link response message:
          -> port
              -> name
              -> MTU
              -> RX
              -> TX
              -> up flag
              -> active flag
              -> properties
                 -> priority
                 -> tolerance
                 -> window
              -> statistics
                  -> rx_info
                  -> rx_fragments
                  -> rx_fragmented
                  -> rx_bundles
                  -> rx_bundled
                  -> tx_info
                  -> tx_fragments
                  -> tx_fragmented
                  -> tx_bundles
                  -> tx_bundled
                  -> msg_prof_tot
                  -> msg_len_cnt
                  -> msg_len_tot
                  -> msg_len_p0
                  -> msg_len_p1
                  -> msg_len_p2
                  -> msg_len_p3
                  -> msg_len_p4
                  -> msg_len_p5
                  -> msg_len_p6
                  -> rx_states
                  -> rx_probes
                  -> rx_nacks
                  -> rx_deferred
                  -> tx_states
                  -> tx_probes
                  -> tx_nacks
                  -> tx_acks
                  -> retransmitted
                  -> duplicates
                  -> link_congs
                  -> max_queue
                  -> avg_queue
      Signed-off-by: NRichard Alpe <richard.alpe@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7be57fc6
  7. 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
  8. 24 8月, 2014 2 次提交
  9. 17 7月, 2014 5 次提交
  10. 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
  11. 12 6月, 2014 1 次提交
    • O
      net: add __pskb_copy_fclone and pskb_copy_for_clone · bad93e9d
      Octavian Purdila 提交于
      There are several instances where a pskb_copy or __pskb_copy is
      immediately followed by an skb_clone.
      
      Add a couple of new functions to allow the copy skb to be allocated
      from the fclone cache and thus speed up subsequent skb_clone calls.
      
      Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Marek Lindner <mareklindner@neomailbox.ch>
      Cc: Simon Wunderlich <sw@simonwunderlich.de>
      Cc: Antonio Quartulli <antonio@meshcoding.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Arvid Brodin <arvid.brodin@alten.se>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Pablo Neira Ayuso <pablo@netfilter.org>
      Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
      Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Allan Stephens <allan.stephens@windriver.com>
      Cc: Andrew Hendry <andrew.hendry@gmail.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Reviewed-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bad93e9d
  12. 15 5月, 2014 1 次提交
  13. 06 5月, 2014 3 次提交
  14. 23 4月, 2014 4 次提交
    • Y
      tipc: use bc_lock to protect node map in bearer structure · 28dd9418
      Ying Xue 提交于
      The node map variable - 'nodes' in bearer structure is only used by
      bclink. When bclink accesses it, bc_lock is held. But when change it,
      for instance, in tipc_bearer_add_dest() or tipc_bearer_remove_dest()
      the bc_lock is not taken at all. To avoid any inconsistent data, we
      should always grab bc_lock while accessing node map variable.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Tested-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28dd9418
    • Y
      tipc: purge tipc_net_lock lock · 7216cd94
      Ying Xue 提交于
      Now tipc routing hierarchy comprises the structures 'node', 'link'and
      'bearer'. The whole hierarchy is protected by a big read/write lock,
      tipc_net_lock, to ensure that nothing is added or removed while code
      is accessing any of these structures. Obviously the locking policy
      makes node, link and bearer components closely bound together so that
      their relationship becomes unnecessarily complex. In the worst case,
      such locking policy not only has a negative influence on performance,
      but also it's prone to lead to deadlock occasionally.
      
      In order o decouple the complex relationship between bearer and node
      as well as link, the locking policy is adjusted as follows:
      
      - Bearer level
        RTNL lock is used on update side, and RCU is used on read side.
        Meanwhile, all bearer instances including broadcast bearer are
        saved into bearer_list array.
      
      - Node and link level
        All node instances are saved into two tipc_node_list and node_htable
        lists. The two lists are protected by node_list_lock on write side,
        and they are guarded with RCU lock on read side. All members in node
        structure including link instances are protected by node spin lock.
      
      - The relationship between bearer and node
        When link accesses bearer, it first needs to find the bearer with
        its bearer identity from the bearer_list array. When bearer accesses
        node, it can iterate the node_htable hash list with the node
        address to find the corresponding node.
      
      In the new locking policy, every component has its private locking
      solution and the relationship between bearer and node is very simple,
      that is, they can find each other with node address or bearer identity
      from node_htable hash list or bearer_list array.
      
      Until now above all changes have been done, so tipc_net_lock can be
      removed safely.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Tested-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7216cd94
    • Y
      tipc: decouple the relationship between bearer and link · 7a2f7d18
      Ying Xue 提交于
      Currently on both paths of message transmission and reception, the
      read lock of tipc_net_lock must be held before bearer is accessed,
      while the write lock of tipc_net_lock has to be taken before bearer
      is configured. Although it can ensure that bearer is always valid on
      the two data paths, link and bearer is closely bound together.
      
      So as the part of effort of removing tipc_net_lock, the locking
      policy of bearer protection will be adjusted as below: on the two
      data paths, RCU is used, and on the configuration path of bearer,
      RTNL lock is applied.
      
      Now RCU just covers the path of message reception. To make it possible
      to protect the path of message transmission with RCU, link should not
      use its stored bearer pointer to access bearer, but it should use the
      bearer identity of its attached bearer as index to get bearer instance
      from bearer_list array, which can help us decouple the relationship
      between bearer and link. As a result, bearer on the path of message
      transmission can be safely protected by RCU when we access bearer_list
      array within RCU lock protection.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Tested-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a2f7d18
    • Y
      tipc: convert bearer_list to RCU list · f8322dfc
      Ying Xue 提交于
      Convert bearer_list to RCU list. It's protected by RTNL lock on
      update side, and RCU read lock is applied to read side.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Tested-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8322dfc
  15. 28 3月, 2014 3 次提交
  16. 19 2月, 2014 1 次提交
    • Y
      tipc: align tipc function names with common naming practice in the network · 247f0f3c
      Ying Xue 提交于
      Rename the following functions, which are shorter and more in line
      with common naming practice in the network subsystem.
      
      tipc_bclink_send_msg->tipc_bclink_xmit
      tipc_bclink_recv_pkt->tipc_bclink_rcv
      tipc_disc_recv_msg->tipc_disc_rcv
      tipc_link_send_proto_msg->tipc_link_proto_xmit
      link_recv_proto_msg->tipc_link_proto_rcv
      link_send_sections_long->tipc_link_iovec_long_xmit
      tipc_link_send_sections_fast->tipc_link_iovec_xmit_fast
      tipc_link_send_sync->tipc_link_sync_xmit
      tipc_link_recv_sync->tipc_link_sync_rcv
      tipc_link_send_buf->__tipc_link_xmit
      tipc_link_send->tipc_link_xmit
      tipc_link_send_names->tipc_link_names_xmit
      tipc_named_recv->tipc_named_rcv
      tipc_link_recv_bundle->tipc_link_bundle_rcv
      tipc_link_dup_send_queue->tipc_link_dup_queue_xmit
      link_send_long_buf->tipc_link_frag_xmit
      
      tipc_multicast->tipc_port_mcast_xmit
      tipc_port_recv_mcast->tipc_port_mcast_rcv
      tipc_port_reject_sections->tipc_port_iovec_reject
      tipc_port_recv_proto_msg->tipc_port_proto_rcv
      tipc_connect->tipc_port_connect
      __tipc_connect->__tipc_port_connect
      __tipc_disconnect->__tipc_port_disconnect
      tipc_disconnect->tipc_port_disconnect
      tipc_shutdown->tipc_port_shutdown
      tipc_port_recv_msg->tipc_port_rcv
      tipc_port_recv_sections->tipc_port_iovec_rcv
      
      release->tipc_release
      accept->tipc_accept
      bind->tipc_bind
      get_name->tipc_getname
      poll->tipc_poll
      send_msg->tipc_sendmsg
      send_packet->tipc_send_packet
      send_stream->tipc_send_stream
      recv_msg->tipc_recvmsg
      recv_stream->tipc_recv_stream
      connect->tipc_connect
      listen->tipc_listen
      shutdown->tipc_shutdown
      setsockopt->tipc_setsockopt
      getsockopt->tipc_getsockopt
      
      Above changes have no impact on current users of the functions.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      247f0f3c
  17. 14 2月, 2014 2 次提交
    • Y
      tipc: remove bearer_lock from tipc_bearer struct · a8304529
      Ying Xue 提交于
      After the earlier commits ("tipc: remove 'links' list from
      tipc_bearer struct") and ("tipc: introduce new spinlock to protect
      struct link_req"), there is no longer any need to protect struct
      link_req or or any link list by use of bearer_lock. Furthermore,
      we have eliminated the need for using bearer_lock during downcalls
      (send) from the link to the bearer, since we have ensured that
      bearers always have a longer life cycle that their associated links,
      and always contain valid data.
      
      So, the only need now for a lock protecting bearers is for guaranteeing
      consistency of the bearer list itself. For this, it is sufficient, at
      least for the time being, to continue applying 'net_lock´ in write mode.
      
      By removing bearer_lock we also pre-empt introduction of issue b) descibed
      in the previous commit "tipc: remove 'links' list from tipc_bearer struct":
      
      "b) When the outer protection from net_lock is gone, taking
          bearer_lock and node_lock in opposite order of method 1) and 2)
          will become an obvious deadlock hazard".
      
      Therefore, we now eliminate the bearer_lock spinlock.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8304529
    • J
      tipc: stricter behavior of message reassembly function · 03b92017
      Jon Paul Maloy 提交于
      The function tipc_link_recv_fragment(struct sk_buff **buf) currently
      leaves the value of the input buffer pointer undefined when it returns,
      except when the return code indicates that the reassembly is complete.
      This despite the fact that it always consumes the input buffer.
      
      Here, we enforce a stricter behavior by this function, ensuring that
      the returned buffer pointer is non-NULL if and only if the reassembly
      is complete. This makes it possible to test for the buffer pointer as
      criteria for successful reassembly.
      
      We also rename the function to tipc_link_frag_rcv(), which is both
      shorter and more in line with common naming practice in the network
      subsystem.
      
      Apart from the new name, these changes have no impact on current
      users of the function, but makes it more practical for use in some
      planned future commits.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03b92017