1. 13 1月, 2015 1 次提交
  2. 25 11月, 2014 1 次提交
  3. 22 11月, 2014 5 次提交
  4. 15 5月, 2014 1 次提交
    • J
      tipc: improve and extend media address conversion functions · 38504c28
      Jon Paul Maloy 提交于
      TIPC currently handles two media specific addresses: Ethernet MAC
      addresses and InfiniBand addresses. Those are kept in three different
      formats:
      
      1) A "raw" format as obtained from the device. This format is known
         only by the media specific adapter code in eth_media.c and
         ib_media.c.
      2) A "generic" internal format, in the form of struct tipc_media_addr,
         which can be referenced and passed around by the generic media-
         unaware code.
      3) A serialized version of the latter, to be conveyed in neighbor
         discovery messages.
      
      Conversion between the three formats can only be done by the media
      specific code, so we have function pointers for this purpose in
      struct tipc_media. Here, the media adapters can install their own
      conversion functions at startup.
      
      We now introduce a new such function, 'raw2addr()', whose purpose
      is to convert from format 1 to format 2 above. We also try to as far
      as possible uniform commenting, variable names and usage of these
      functions, with the purpose of making them more comprehensible.
      
      We can now also remove the function tipc_l2_media_addr_set(), whose
      job is done better by the new function.
      
      Finally, we expand the field for serialized addresses (format 3)
      in discovery messages from 20 to 32 bytes. This is permitted
      according to the spec, and reduces the risk of problems when we
      add new media in the future.
      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>
      38504c28
  5. 23 4月, 2014 9 次提交
  6. 29 3月, 2014 2 次提交
  7. 28 3月, 2014 3 次提交
  8. 13 3月, 2014 1 次提交
  9. 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
  10. 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
  11. 15 1月, 2014 1 次提交
  12. 08 1月, 2014 1 次提交
  13. 05 1月, 2014 1 次提交
  14. 11 12月, 2013 4 次提交
  15. 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
  16. 19 10月, 2013 2 次提交
  17. 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