2006-01-02 18:04:38 +00:00
|
|
|
/*
|
|
|
|
* net/tipc/net.c: TIPC network routing code
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
tipc: introduce message evaluation function
When a message arrives in a node and finds no destination
socket, we may need to drop it, reject it, or forward it after
a secondary destination lookup. The latter two cases currently
results in a code path that is perceived as complex, because it
follows a deep call chain via obscure functions such as
net_route_named_msg() and net_route_msg().
We now introduce a function, tipc_msg_eval(), that takes the
decision about whether such a message should be rejected or
forwarded, but leaves it to the caller to actually perform
the indicated action.
If the decision is 'reject', it is still the task of the recently
introduced function tipc_msg_reverse() to take the final decision
about whether the message is rejectable or not. In the latter case
it drops the message.
As a result of this change, we can finally eliminate the function
net_route_named_msg(), and hence become independent of net_route_msg().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-26 01:41:36 +00:00
|
|
|
* Copyright (c) 1995-2006, 2014, Ericsson AB
|
2011-02-24 18:20:20 +00:00
|
|
|
* Copyright (c) 2005, 2010-2011, Wind River Systems
|
2006-01-02 18:04:38 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
2006-01-11 12:30:43 +00:00
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. Neither the names of the copyright holders nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived from
|
|
|
|
* this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* Alternatively, this software may be distributed under the terms of the
|
|
|
|
* GNU General Public License ("GPL") version 2 as published by the Free
|
|
|
|
* Software Foundation.
|
2006-01-02 18:04:38 +00:00
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
|
|
|
|
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "core.h"
|
|
|
|
#include "net.h"
|
|
|
|
#include "name_distr.h"
|
|
|
|
#include "subscr.h"
|
2014-05-14 09:39:15 +00:00
|
|
|
#include "socket.h"
|
2011-02-25 23:42:52 +00:00
|
|
|
#include "node.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/*
|
2006-01-02 18:04:38 +00:00
|
|
|
* The TIPC locking policy is designed to ensure a very fine locking
|
|
|
|
* granularity, permitting complete parallel access to individual
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* port and node/link instances. The code consists of four major
|
2006-01-02 18:04:38 +00:00
|
|
|
* locking domains, each protected with their own disjunct set of locks.
|
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* 1: The bearer level.
|
|
|
|
* RTNL lock is used to serialize the process of configuring bearer
|
|
|
|
* on update side, and RCU lock is applied on read side to make
|
|
|
|
* bearer instance valid on both paths of message transmission and
|
|
|
|
* reception.
|
2006-01-02 18:04:38 +00:00
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* 2: The 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. Especially node
|
|
|
|
* instance is destroyed only when TIPC module is removed, and we can
|
|
|
|
* confirm that there has no any user who is accessing the node at the
|
|
|
|
* moment. Therefore, Except for iterating the two lists within RCU
|
|
|
|
* protection, it's no needed to hold RCU that we access node instance
|
|
|
|
* in other places.
|
2006-01-02 18:04:38 +00:00
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* In addition, all members in node structure including link instances
|
|
|
|
* are protected by node spin lock.
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* 3: The transport level of the protocol.
|
|
|
|
* This consists of the structures port, (and its user level
|
|
|
|
* representations, such as user_port and tipc_sock), reference and
|
|
|
|
* tipc_user (port.c, reg.c, socket.c).
|
2006-01-02 18:04:38 +00:00
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* This layer has four different locks:
|
2006-01-02 18:04:38 +00:00
|
|
|
* - The tipc_port spin_lock. This is protecting each port instance
|
2007-02-09 14:25:21 +00:00
|
|
|
* from parallel data access and removal. Since we can not place
|
|
|
|
* this lock in the port itself, it has been placed in the
|
2006-01-02 18:04:38 +00:00
|
|
|
* corresponding reference table entry, which has the same life
|
2007-02-09 14:25:21 +00:00
|
|
|
* cycle as the module. This entry is difficult to access from
|
|
|
|
* outside the TIPC core, however, so a pointer to the lock has
|
|
|
|
* been added in the port instance, -to be used for unlocking
|
2006-01-02 18:04:38 +00:00
|
|
|
* only.
|
2007-02-09 14:25:21 +00:00
|
|
|
* - A read/write lock to protect the reference table itself (teg.c).
|
|
|
|
* (Nobody is using read-only access to this, so it can just as
|
2006-01-02 18:04:38 +00:00
|
|
|
* well be changed to a spin_lock)
|
|
|
|
* - A spin lock to protect the registry of kernel/driver users (reg.c)
|
2007-02-09 14:25:21 +00:00
|
|
|
* - A global spin_lock (tipc_port_lock), which only task is to ensure
|
2006-01-02 18:04:38 +00:00
|
|
|
* consistency where more than one port is involved in an operation,
|
|
|
|
* i.e., whe a port is part of a linked list of ports.
|
|
|
|
* There are two such lists; 'port_list', which is used for management,
|
|
|
|
* and 'wait_list', which is used to queue ports during congestion.
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
* 4: The name table (name_table.c, name_distr.c, subscription.c)
|
2007-02-09 14:25:21 +00:00
|
|
|
* - There is one big read/write-lock (tipc_nametbl_lock) protecting the
|
|
|
|
* overall name table structure. Nothing must be added/removed to
|
2006-01-02 18:04:38 +00:00
|
|
|
* this structure without holding write access to it.
|
|
|
|
* - There is one local spin_lock per sub_sequence, which can be seen
|
2006-01-17 23:38:21 +00:00
|
|
|
* as a sub-domain to the tipc_nametbl_lock domain. It is used only
|
2006-01-02 18:04:38 +00:00
|
|
|
* for translation operations, and is needed because a translation
|
|
|
|
* steps the root of the 'publication' linked list between each lookup.
|
2006-01-17 23:38:21 +00:00
|
|
|
* This is always used within the scope of a tipc_nametbl_lock(read).
|
2006-01-02 18:04:38 +00:00
|
|
|
* - A local spin_lock protecting the queue of subscriber events.
|
|
|
|
*/
|
|
|
|
|
2014-05-05 00:56:16 +00:00
|
|
|
int tipc_net_start(u32 addr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
char addr_string[16];
|
2014-05-05 00:56:16 +00:00
|
|
|
int res;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2008-05-21 21:55:04 +00:00
|
|
|
tipc_own_addr = addr;
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_named_reinit();
|
2014-08-22 22:09:14 +00:00
|
|
|
tipc_sk_reinit();
|
2014-05-05 00:56:16 +00:00
|
|
|
res = tipc_bclink_init();
|
|
|
|
if (res)
|
|
|
|
return res;
|
|
|
|
|
2014-04-03 06:28:01 +00:00
|
|
|
tipc_nametbl_publish(TIPC_CFG_SRV, tipc_own_addr, tipc_own_addr,
|
|
|
|
TIPC_ZONE_SCOPE, 0, tipc_own_addr);
|
tipc: purge tipc_net_lock lock
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: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 02:55:48 +00:00
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_info("Started in network mode\n");
|
|
|
|
pr_info("Own node address %s, network identity %u\n",
|
|
|
|
tipc_addr_string_fill(addr_string, tipc_own_addr), tipc_net_id);
|
2014-05-05 00:56:16 +00:00
|
|
|
return 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2006-01-17 23:38:21 +00:00
|
|
|
void tipc_net_stop(void)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2011-11-08 18:48:28 +00:00
|
|
|
if (!tipc_own_addr)
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
2014-03-27 04:54:36 +00:00
|
|
|
|
2014-04-03 06:28:01 +00:00
|
|
|
tipc_nametbl_withdraw(TIPC_CFG_SRV, tipc_own_addr, 0, tipc_own_addr);
|
2014-04-21 02:55:44 +00:00
|
|
|
rtnl_lock();
|
2011-10-20 13:48:05 +00:00
|
|
|
tipc_bearer_stop();
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_bclink_stop();
|
2014-03-27 04:54:36 +00:00
|
|
|
tipc_node_stop();
|
2014-04-21 02:55:44 +00:00
|
|
|
rtnl_unlock();
|
2014-03-27 04:54:36 +00:00
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_info("Left network mode\n");
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|