1. 23 4月, 2014 4 次提交
  2. 29 3月, 2014 2 次提交
  3. 28 3月, 2014 3 次提交
  4. 13 3月, 2014 1 次提交
  5. 22 2月, 2014 1 次提交
    • Y
      tipc: make bearer set up in module insertion stage · 970122fd
      Ying Xue 提交于
      Accidentally a side effect is involved by commit 6e967adf(tipc:
      relocate common functions from media to bearer). Now tipc stack
      handler of receiving packets from netdevices as well as netdevice
      notification handler are registered when bearer is enabled rather
      than tipc module initialization stage, but the two handlers are
      both unregistered in tipc module exit phase. If tipc module is
      inserted and then immediately removed, the following warning
      message will appear:
      
      "dev_remove_pack: ffffffffa0380940 not found"
      
      This is because in module insertion stage tipc stack packet handler
      is not registered at all, but in module exit phase dev_remove_pack()
      needs to remove it. Of course, dev_remove_pack() cannot find tipc
      protocol handler from the kernel protocol handler list so that the
      warning message is printed out.
      
      But if registering the two handlers is adjusted from enabling bearer
      phase into inserting module stage, the warning message will be
      eliminated. Due to this change, tipc_core_start_net() and
      tipc_core_stop_net() can be deleted as well.
      Reported-by: NWang Weidong <wangweidong1@huawei.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Erik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      970122fd
  6. 14 2月, 2014 5 次提交
    • 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: delay delete of link when failover is needed · 7d33939f
      Jon Paul Maloy 提交于
      When a bearer is disabled, all its attached links are deleted.
      Ideally, we should do link failover to redundant links on other bearers,
      if there are any, in such cases. This would be consistent with current
      behavior when a link is reset, but not deleted. However, due to the
      complexity involved, and the (wrongly) perceived low demand for this
      feature, it was never implemented until now.
      
      We mark the doomed link for deletion with a new flag, but wait until the
      failover process is finished before we actually delete it. With the
      improved link tunnelling/failover code introduced earlier in this commit
      series, it is now easy to identify a spot in the code where the failover
      is finished and it is safe to delete the marked link. Moreover, the test
      for the flag and the deletion can be done synchronously, and outside the
      most time critical data path.
      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>
      7d33939f
    • Y
      tipc: remove 'links' list from tipc_bearer struct · c61dd61d
      Ying Xue 提交于
      In our ongoing effort to simplify the TIPC locking structure,
      we see a need to remove the linked list for tipc_links
      in the bearer. This can be explained as follows.
      
      Currently, we have three different ways to access a link,
      via three different lists/tables:
      
      1: Via a node hash table:
         Used by the time-critical outgoing/incoming data paths.
         (e.g. link_send_sections_fast() and tipc_recv_msg() ):
      
      grab net_lock(read)
         find node from node hash table
         grab node_lock
             select link
             grab bearer_lock
                send_msg()
             release bearer_lock
         release node lock
      release net_lock
      
      2: Via a global linked list for nodes:
         Used by configuration commands (link_cmd_set_value())
      
      grab net_lock(read)
         find node and link from global node list (using link name)
         grab node_lock
             update link
         release node lock
      release net_lock
      
      (Same locking order as above. No problem.)
      
      3: Via the bearer's linked link list:
         Used by notifications from interface (e.g. tipc_disable_bearer() )
      
      grab net_lock(write)
         grab bearer_lock
            get link ptr from bearer's link list
            get node from link
            grab node_lock
               delete link
            release node lock
         release bearer_lock
      release net_lock
      
      (Different order from above, but works because we grab the
      outer net_lock in write mode first, excluding all other access.)
      
      The first major goal in our simplification effort is to get rid
      of the "big" net_lock, replacing it with rcu-locks when accessing
      the node list and node hash array. This will come in a later patch
      series.
      
      But to get there we first need to rewrite access methods ##2 and 3,
      since removal of net_lock would introduce three major problems:
      
      a) In access method #2, we access the link before taking the
         protecting node_lock. This will not work once net_lock is gone,
         so we will have to change the access order. We will deal with
         this in a later commit in this series, "tipc: add node lock
         protection to link found by link_find_link()".
      
      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. This is fixed in the
         commit ("tipc: remove bearer_lock from tipc_bearer struct")
         later in this series.
      
      c) Similar to what is described in problem a), access method #3
         starts with using a link pointer that is unprotected by node_lock,
         in order to via that pointer find the correct node struct and
         lock it. Before we remove net_lock, this access order must be
         altered. This is what we do with this commit.
      
      We can avoid introducing problem problem c) by even here using the
      global node list to find the node, before accessing its links. When
      we loop though the node list we use the own bearer identity as search
      criteria, thus easily finding the links that are associated to the
      resetting/disabling bearer. It should be noted that although this
      method is somewhat slower than the current list traversal, it is in
      no way time critical. This is only about resetting or deleting links,
      something that must be considered relatively infrequent events.
      
      As a bonus, we can get rid of the mutual pointers between links and
      bearers. After this commit, pointer dependency go in one direction
      only: from the link to the bearer.
      
      This commit pre-empts introduction of problem c) as described above.
      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>
      c61dd61d
    • Y
      tipc: move code for deleting links from bearer.c to link.c · 8d8439b6
      Ying Xue 提交于
      We break out the code for deleting attached links in the
      function bearer_disable(), and define a new function named
      tipc_link_delete_list() to do this job.
      
      This commit incurs no functional changes, but makes the code of
      function bearer_disable() cleaner. It is also a preparation
      for a more important change to the bearer code, in a subsequent
      commit in this series.
      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>
      8d8439b6
    • Y
      tipc: move code for resetting links from bearer.c to link.c · e0ca2c30
      Ying Xue 提交于
      We break out the code for resetting attached links in the
      function tipc_reset_bearer(), and define a new function named
      tipc_link_reset_list() to do this job.
      
      This commit incurs no functional changes, but makes the code
      of function tipc_reset_bearer() cleaner. It is also a preparation
      for a more important change to the bearer code, in a subsequent
      commit in this series.
      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>
      e0ca2c30
  7. 15 1月, 2014 1 次提交
  8. 08 1月, 2014 1 次提交
  9. 05 1月, 2014 1 次提交
  10. 11 12月, 2013 4 次提交
  11. 10 12月, 2013 1 次提交
    • E
      tipc: remove interface state mirroring in bearer · 512137ee
      Erik Hugne 提交于
      struct 'tipc_bearer' is a generic representation of the underlying
      media type, and exists in a one-to-one relationship to each interface
      TIPC is using. The struct contains a 'blocked' flag that mirrors the
      operational and execution state of the represented interface, and is
      updated through notification calls from the latter. The users of
      tipc_bearer are checking this flag before each attempt to send a
      packet via the interface.
      
      This state mirroring serves no purpose in the current code base. TIPC
      links will not discover a media failure any faster through this
      mechanism, and in reality the flag only adds overhead at packet
      sending and reception.
      
      Furthermore, the fact that the flag needs to be protected by a spinlock
      aggregated into tipc_bearer has turned out to cause a serious and
      completely unnecessary deadlock problem.
      
      CPU0                                    CPU1
      ----                                    ----
      Time 0: bearer_disable()                link_timeout()
      Time 1:   spin_lock_bh(&b_ptr->lock)      tipc_link_push_queue()
      Time 2:   tipc_link_delete()                tipc_bearer_blocked(b_ptr)
      Time 3:     k_cancel_timer(&req->timer)       spin_lock_bh(&b_ptr->lock)
      Time 4:       del_timer_sync(&req->timer)
      
      I.e., del_timer_sync() on CPU0 never returns, because the timer handler
      on CPU1 is waiting for the bearer lock.
      
      We eliminate the 'blocked' flag from struct tipc_bearer, along with all
      tests on this flag. This not only resolves the deadlock, but also
      simplifies and speeds up the data path execution of TIPC. It also fits
      well into our ongoing effort to make the locking policy simpler and
      more manageable.
      
      An effect of this change is that we can get rid of functions such as
      tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
      We replace the latter with a new function, tipc_reset_bearer(), which
      resets all links associated to the bearer immediately after an
      interface goes down.
      
      A user might notice one slight change in link behaviour after this
      change. When an interface goes down, (e.g. through a NETDEV_DOWN
      event) all attached links will be reset immediately, instead of
      leaving it to each link to detect the failure through a timer-driven
      mechanism. We consider this an improvement, and see no obvious risks
      with the new behavior.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-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>
      512137ee
  12. 19 10月, 2013 2 次提交
  13. 12 8月, 2013 1 次提交
    • D
      tipc: avoid possible deadlock while enable and disable bearer · d4cca39d
      dingtianhong 提交于
      We met lockdep warning when enable and disable the bearer for commands such as:
      
      tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
      tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
      
      ---------------------------------------------------
      
      [  327.693595] ======================================================
      [  327.693994] [ INFO: possible circular locking dependency detected ]
      [  327.694519] 3.11.0-rc3-wwd-default #4 Tainted: G           O
      [  327.694882] -------------------------------------------------------
      [  327.695385] tipc-config/5825 is trying to acquire lock:
      [  327.695754]  (((timer))#2){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0
      [  327.696018]
      [  327.696018] but task is already holding lock:
      [  327.696018]  (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+  0xdd/0x120 [tipc]
      [  327.696018]
      [  327.696018] which lock already depends on the new lock.
      [  327.696018]
      [  327.696018]
      [  327.696018] the existing dependency chain (in reverse order) is:
      [  327.696018]
      [  327.696018] -> #1 (&(&b_ptr->lock)->rlock){+.-...}:
      [  327.696018]        [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]        [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]        [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]        [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
      [  327.696018]        [<ffffffffa02c5d48>] disc_timeout+0x18/0xd0 [tipc]
      [  327.696018]        [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0
      [  327.696018]        [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0
      [  327.696018]        [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
      [  327.696018]        [<ffffffff81053a35>] irq_exit+0xd5/0xe0
      [  327.696018]        [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60
      [  327.696018]        [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80
      [  327.696018]        [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30
      [  327.696018]        [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280
      [  327.696018]        [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20
      [  327.696018]        [<ffffffff81031589>] start_secondary+0x89/0x90
      [  327.696018]
      [  327.696018] -> #0 (((timer))#2){+.-...}:
      [  327.696018]        [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
      [  327.696018]        [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]        [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]        [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]        [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
      [  327.696018]        [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
      [  327.696018]        [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
      [  327.696018]        [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
      [  327.696018]        [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
      [  327.696018]        [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
      [  327.696018]        [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
      [  327.696018]        [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
      [  327.696018]        [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
      [  327.696018]        [<ffffffff8143e617>] genl_rcv+0x27/0x40
      [  327.696018]        [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
      [  327.696018]        [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
      [  327.696018]        [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
      [  327.696018]        [<ffffffff813f7957>] sock_aio_write+0x107/0x120
      [  327.696018]        [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
      [  327.696018]        [<ffffffff8117fc56>] vfs_write+0x186/0x190
      [  327.696018]        [<ffffffff811803e0>] SyS_write+0x60/0xb0
      [  327.696018]        [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
      [  327.696018]
      [  327.696018] other info that might help us debug this:
      [  327.696018]
      [  327.696018]  Possible unsafe locking scenario:
      [  327.696018]
      [  327.696018]        CPU0                    CPU1
      [  327.696018]        ----                    ----
      [  327.696018]   lock(&(&b_ptr->lock)->rlock);
      [  327.696018]                                lock(((timer))#2);
      [  327.696018]                                lock(&(&b_ptr->lock)->rlock);
      [  327.696018]   lock(((timer))#2);
      [  327.696018]
      [  327.696018]  *** DEADLOCK ***
      [  327.696018]
      [  327.696018] 5 locks held by tipc-config/5825:
      [  327.696018]  #0:  (cb_lock){++++++}, at: [<ffffffff8143e608>] genl_rcv+0x18/0x40
      [  327.696018]  #1:  (genl_mutex){+.+.+.}, at: [<ffffffff8143ed66>] genl_rcv_msg+0xa6/0xd0
      [  327.696018]  #2:  (config_mutex){+.+.+.}, at: [<ffffffffa02bf889>] tipc_cfg_do_cmd+0x39/ 0x550 [tipc]
      [  327.696018]  #3:  (tipc_net_lock){++.-..}, at: [<ffffffffa02be738>] tipc_disable_bearer+ 0x18/0x60 [tipc]
      [  327.696018]  #4:  (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>]             bearer_disable+0xdd/0x120 [tipc]
      [  327.696018]
      [  327.696018] stack backtrace:
      [  327.696018] CPU: 2 PID: 5825 Comm: tipc-config Tainted: G           O 3.11.0-rc3-wwd-    default #4
      [  327.696018] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  327.696018]  00000000ffffffff ffff880037fa77a8 ffffffff814d03dd 0000000000000000
      [  327.696018]  ffff880037fa7808 ffff880037fa77e8 ffffffff810b1c4f 0000000037fa77e8
      [  327.696018]  ffff880037fa7808 ffff880037e4db40 0000000000000000 ffff880037e4e318
      [  327.696018] Call Trace:
      [  327.696018]  [<ffffffff814d03dd>] dump_stack+0x4d/0xa0
      [  327.696018]  [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120
      [  327.696018]  [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
      [  327.696018]  [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]  [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110
      [  327.696018]  [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]  [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]  [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
      [  327.696018]  [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
      [  327.696018]  [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
      [  327.696018]  [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
      [  327.696018]  [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
      [  327.696018]  [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
      [  327.696018]  [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
      [  327.696018]  [<ffffffff81218783>] ? security_capable+0x13/0x20
      [  327.696018]  [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
      [  327.696018]  [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
      [  327.696018]  [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
      [  327.696018]  [<ffffffff8143ecc0>] ? genl_lock+0x20/0x20
      [  327.696018]  [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
      [  327.696018]  [<ffffffff8143e608>] ? genl_rcv+0x18/0x40
      [  327.696018]  [<ffffffff8143e617>] genl_rcv+0x27/0x40
      [  327.696018]  [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
      [  327.696018]  [<ffffffff81289d7c>] ? memcpy_fromiovec+0x6c/0x90
      [  327.696018]  [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
      [  327.696018]  [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
      [  327.696018]  [<ffffffff813f7957>] sock_aio_write+0x107/0x120
      [  327.696018]  [<ffffffff813fe29c>] ? release_sock+0x8c/0xa0
      [  327.696018]  [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
      [  327.696018]  [<ffffffff8117fa24>] ? rw_verify_area+0x54/0x100
      [  327.696018]  [<ffffffff8117fc56>] vfs_write+0x186/0x190
      [  327.696018]  [<ffffffff811803e0>] SyS_write+0x60/0xb0
      [  327.696018]  [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
      
      -----------------------------------------------------------------------
      
      The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
      the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
      work, so the dead lock occurs.
      
      We should unlock the b_ptr->lock when del the disc_timeout().
      
      Remove link_timeout() still met the same problem, the patch:
      
      http://article.gmane.org/gmane.network.tipc.general/4380
      
      fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
      Signed-off-by: NWang Weidong <wangweidong1@huawei.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4cca39d
  14. 18 4月, 2013 2 次提交
    • P
      tipc: add InfiniBand media type · a29a194a
      Patrick McHardy 提交于
      Add InfiniBand media type based on the ethernet media type.
      
      The only real difference is that in case of InfiniBand, we need the entire
      20 bytes of space reserved for media addresses, so the TIPC media type ID is
      not explicitly stored in the packet payload.
      
      Sample output of tipc-config:
      
      # tipc-config -v -addr -netid -nt=all -p -m -b -n -ls
      
      node address: <10.1.4>
      current network id: 4711
      Type       Lower      Upper      Port Identity              Publication Scope
      0          167776257  167776257  <10.1.1:1855512577>        1855512578  cluster
                 167776260  167776260  <10.1.4:1216454657>        1216454658  zone
      1          1          1          <10.1.4:1216479235>        1216479236  node
      Ports:
      1216479235: bound to {1,1}
      1216454657: bound to {0,167776260}
      Media:
      eth
      ib
      Bearers:
      ib:ib0
      Nodes known:
      <10.1.1>: up
      Link <broadcast-link>
        Window:20 packets
        RX packets:0 fragments:0/0 bundles:0/0
        TX packets:0 fragments:0/0 bundles:0/0
        RX naks:0 defs:0 dups:0
        TX naks:0 acks:0 dups:0
        Congestion bearer:0 link:0  Send queue max:0 avg:0
      
      Link <10.1.4:ib0-10.1.1:ib0>
        ACTIVE  MTU:2044  Priority:10  Tolerance:1500 ms  Window:50 packets
        RX packets:80 fragments:0/0 bundles:0/0
        TX packets:40 fragments:0/0 bundles:0/0
        TX profile sample:22 packets  average:54 octets
        0-64:100% -256:0% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0%
        RX states:410 probes:213 naks:0 defs:0 dups:0
        TX states:410 probes:197 naks:0 acks:0 dups:0
        Congestion bearer:0 link:0  Send queue max:1 avg:0
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a29a194a
    • P
      tipc: move bcast_addr from struct tipc_media to struct tipc_bearer · 8aeb89f2
      Patrick McHardy 提交于
      Some network protocols, like InfiniBand, don't have a fixed broadcast
      address but one that depends on the configuration. Move the bcast_addr
      to struct tipc_bearer and initialize it with the broadcast address of
      the network device when the bearer is enabled.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8aeb89f2
  15. 22 11月, 2012 1 次提交
    • Y
      tipc: remove the bearer congestion mechanism · 3c294cb3
      Ying Xue 提交于
      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: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      3c294cb3
  16. 20 8月, 2012 2 次提交
  17. 14 7月, 2012 2 次提交
    • E
      tipc: phase out most of the struct print_buf usage · dc1aed37
      Erik Hugne 提交于
      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: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      dc1aed37
    • E
      tipc: use standard printk shortcut macros (pr_err etc.) · 2cf8aa19
      Erik Hugne 提交于
      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: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      [PG: use pr_fmt as suggested by Joe Perches <joe@perches.com>]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2cf8aa19
  18. 11 7月, 2012 1 次提交
  19. 01 5月, 2012 1 次提交
    • P
      tipc: compress out gratuitous extra carriage returns · 617d3c7a
      Paul Gortmaker 提交于
      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: NPaul Gortmaker <paul.gortmaker@windriver.com>
      617d3c7a
  20. 20 4月, 2012 1 次提交
    • A
      tipc: Add routines for safe checking of node's network address · 336ebf5b
      Allan Stephens 提交于
      Introduces routines that test whether a given network address is
      equal to a node's own network address or if it lies within the node's
      own network cluster, and which work properly regardless of whether
      the node is using the default network address <0.0.0> or a non-zero
      network address that is assigned later on. In essence, these routines
      ensure that address <0.0.0> is treated as an alias for "this node",
      regardless of which network address the node is actually using.
      
      Old users of the pre-existing more strict match in_own_cluster()
      have been accordingly redirected to what is now called
      in_own_cluster_exact() --- which does not extend matching to <0,0,0>.
      Signed-off-by: NAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      336ebf5b
  21. 25 2月, 2012 2 次提交
  22. 30 12月, 2011 1 次提交