2006-01-02 21:04:38 +03:00
|
|
|
/*
|
|
|
|
* net/tipc/discover.c
|
2007-02-09 17:25:21 +03:00
|
|
|
*
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
* Copyright (c) 2003-2006, 2014-2018, Ericsson AB
|
2011-01-07 21:00:11 +03:00
|
|
|
* Copyright (c) 2005-2006, 2010-2011, Wind River Systems
|
2006-01-02 21:04:38 +03:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
2006-01-11 15:30:43 +03:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
2006-01-02 21:04:38 +03:00
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
2006-01-11 15:30:43 +03: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.
|
2006-01-02 21:04:38 +03:00
|
|
|
*
|
2006-01-11 15:30:43 +03:00
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* 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
|
2006-01-02 21:04:38 +03:00
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "core.h"
|
2015-07-16 23:54:20 +03:00
|
|
|
#include "node.h"
|
2006-01-02 21:04:38 +03:00
|
|
|
#include "discover.h"
|
|
|
|
|
2015-01-09 10:27:00 +03:00
|
|
|
/* min delay during bearer start up */
|
2018-03-22 22:42:46 +03:00
|
|
|
#define TIPC_DISC_INIT msecs_to_jiffies(125)
|
2015-01-09 10:27:00 +03:00
|
|
|
/* max delay if bearer has no links */
|
2018-03-22 22:42:46 +03:00
|
|
|
#define TIPC_DISC_FAST msecs_to_jiffies(1000)
|
2015-01-09 10:27:00 +03:00
|
|
|
/* max delay if bearer has links */
|
2018-03-22 22:42:46 +03:00
|
|
|
#define TIPC_DISC_SLOW msecs_to_jiffies(60000)
|
2015-01-09 10:27:00 +03:00
|
|
|
/* indicates no timer in use */
|
2018-03-22 22:42:46 +03:00
|
|
|
#define TIPC_DISC_INACTIVE 0xffffffff
|
2006-01-02 21:04:38 +03:00
|
|
|
|
|
|
|
/**
|
2018-03-22 22:42:46 +03:00
|
|
|
* struct tipc_discoverer - information about an ongoing link setup request
|
tipc: decouple the relationship between bearer and link
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: 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 06:55:46 +04:00
|
|
|
* @bearer_id: identity of bearer issuing requests
|
2015-01-09 10:27:06 +03:00
|
|
|
* @net: network namespace instance
|
2006-01-02 21:04:38 +03:00
|
|
|
* @dest: destination address for request messages
|
tipc: decouple the relationship between bearer and link
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: 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 06:55:46 +04:00
|
|
|
* @domain: network domain to which links can be established
|
2011-04-22 04:05:25 +04:00
|
|
|
* @num_nodes: number of nodes currently discovered (i.e. with an active link)
|
2014-01-08 02:02:43 +04:00
|
|
|
* @lock: spinlock for controlling access to requests
|
2018-03-22 22:42:46 +03:00
|
|
|
* @skb: request message to be (repeatedly) sent
|
2006-01-02 21:04:38 +03:00
|
|
|
* @timer: timer governing period between requests
|
|
|
|
* @timer_intv: current interval between requests (in ms)
|
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_discoverer {
|
tipc: decouple the relationship between bearer and link
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: 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 06:55:46 +04:00
|
|
|
u32 bearer_id;
|
2006-01-02 21:04:38 +03:00
|
|
|
struct tipc_media_addr dest;
|
2015-01-09 10:27:06 +03:00
|
|
|
struct net *net;
|
tipc: decouple the relationship between bearer and link
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: 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 06:55:46 +04:00
|
|
|
u32 domain;
|
2011-04-22 04:05:25 +04:00
|
|
|
int num_nodes;
|
2014-01-08 02:02:43 +04:00
|
|
|
spinlock_t lock;
|
2018-03-22 22:42:46 +03:00
|
|
|
struct sk_buff *skb;
|
2006-01-02 21:04:38 +03:00
|
|
|
struct timer_list timer;
|
2015-01-09 10:27:00 +03:00
|
|
|
unsigned long timer_intv;
|
2006-01-02 21:04:38 +03:00
|
|
|
};
|
|
|
|
|
2007-02-09 17:25:21 +03:00
|
|
|
/**
|
2006-01-18 02:38:21 +03:00
|
|
|
* tipc_disc_init_msg - initialize a link setup message
|
2015-01-09 10:27:04 +03:00
|
|
|
* @net: the applicable net namespace
|
2020-11-29 21:32:50 +03:00
|
|
|
* @skb: buffer containing message
|
2020-07-13 02:15:14 +03:00
|
|
|
* @mtyp: message type (request or response)
|
2015-11-19 22:30:47 +03:00
|
|
|
* @b: ptr to bearer issuing message
|
2006-01-02 21:04:38 +03:00
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
static void tipc_disc_init_msg(struct net *net, struct sk_buff *skb,
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
u32 mtyp, struct tipc_bearer *b)
|
2006-01-02 21:04:38 +03:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_net *tn = tipc_net(net);
|
2015-11-19 22:30:47 +03:00
|
|
|
u32 dest_domain = b->domain;
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_msg *hdr;
|
2006-01-02 21:04:38 +03:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
hdr = buf_msg(skb);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
tipc_msg_init(tn->trial_addr, hdr, LINK_CONFIG, mtyp,
|
2015-03-05 12:23:48 +03:00
|
|
|
MAX_H_SIZE, dest_domain);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
msg_set_size(hdr, MAX_H_SIZE + NODE_ID_LEN);
|
2018-03-22 22:42:46 +03:00
|
|
|
msg_set_non_seq(hdr, 1);
|
|
|
|
msg_set_node_sig(hdr, tn->random);
|
|
|
|
msg_set_node_capabilities(hdr, TIPC_NODE_CAPABILITIES);
|
|
|
|
msg_set_dest_domain(hdr, dest_domain);
|
|
|
|
msg_set_bc_netid(hdr, tn->net_id);
|
|
|
|
b->media->addr2msg(msg_media_addr(hdr), &b->addr);
|
tipc: improve throughput between nodes in netns
Currently, TIPC transports intra-node user data messages directly
socket to socket, hence shortcutting all the lower layers of the
communication stack. This gives TIPC very good intra node performance,
both regarding throughput and latency.
We now introduce a similar mechanism for TIPC data traffic across
network namespaces located in the same kernel. On the send path, the
call chain is as always accompanied by the sending node's network name
space pointer. However, once we have reliably established that the
receiving node is represented by a namespace on the same host, we just
replace the namespace pointer with the receiving node/namespace's
ditto, and follow the regular socket receive patch though the receiving
node. This technique gives us a throughput similar to the node internal
throughput, several times larger than if we let the traffic go though
the full network stacks. As a comparison, max throughput for 64k
messages is four times larger than TCP throughput for the same type of
traffic.
To meet any security concerns, the following should be noted.
- All nodes joining a cluster are supposed to have been be certified
and authenticated by mechanisms outside TIPC. This is no different for
nodes/namespaces on the same host; they have to auto discover each
other using the attached interfaces, and establish links which are
supervised via the regular link monitoring mechanism. Hence, a kernel
local node has no other way to join a cluster than any other node, and
have to obey to policies set in the IP or device layers of the stack.
- Only when a sender has established with 100% certainty that the peer
node is located in a kernel local namespace does it choose to let user
data messages, and only those, take the crossover path to the receiving
node/namespace.
- If the receiving node/namespace is removed, its namespace pointer
is invalidated at all peer nodes, and their neighbor link monitoring
will eventually note that this node is gone.
- To ensure the "100% certainty" criteria, and prevent any possible
spoofing, received discovery messages must contain a proof that the
sender knows a common secret. We use the hash mix of the sending
node/namespace for this purpose, since it can be accessed directly by
all other namespaces in the kernel. Upon reception of a discovery
message, the receiver checks this proof against all the local
namespaces'hash_mix:es. If it finds a match, that, along with a
matching node id and cluster id, this is deemed sufficient proof that
the peer node in question is in a local namespace, and a wormhole can
be opened.
- We should also consider that TIPC is intended to be a cluster local
IPC mechanism (just like e.g. UNIX sockets) rather than a network
protocol, and hence we think it can justified to allow it to shortcut the
lower protocol layers.
Regarding traceability, we should notice that since commit 6c9081a3915d
("tipc: add loopback device tracking") it is possible to follow the node
internal packet flow by just activating tcpdump on the loopback
interface. This will be true even for this mechanism; by activating
tcpdump on the involved nodes' loopback interfaces their inter-name
space messaging can easily be tracked.
v2:
- update 'net' pointer when node left/rejoined
v3:
- grab read/write lock when using node ref obj
v4:
- clone traffics between netns to loopback
Suggested-by: Jon Maloy <jon.maloy@ericsson.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-29 03:51:21 +03:00
|
|
|
msg_set_peer_net_hash(hdr, tipc_net_hash_mixes(net, tn->random));
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
msg_set_node_id(hdr, tipc_own_id(net));
|
2018-03-22 22:42:46 +03:00
|
|
|
}
|
|
|
|
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
static void tipc_disc_msg_xmit(struct net *net, u32 mtyp, u32 dst,
|
|
|
|
u32 src, u32 sugg_addr,
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_media_addr *maddr,
|
|
|
|
struct tipc_bearer *b)
|
|
|
|
{
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
struct tipc_msg *hdr;
|
2018-03-22 22:42:46 +03:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
skb = tipc_buf_acquire(MAX_H_SIZE + NODE_ID_LEN, GFP_ATOMIC);
|
2018-03-22 22:42:46 +03:00
|
|
|
if (!skb)
|
|
|
|
return;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
hdr = buf_msg(skb);
|
2018-03-22 22:42:46 +03:00
|
|
|
tipc_disc_init_msg(net, skb, mtyp, b);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
msg_set_sugg_node_addr(hdr, sugg_addr);
|
|
|
|
msg_set_dest_domain(hdr, dst);
|
2018-03-22 22:42:46 +03:00
|
|
|
tipc_bearer_xmit_skb(net, b->identity, skb, maddr);
|
2006-01-02 21:04:38 +03:00
|
|
|
}
|
|
|
|
|
2006-10-17 08:44:59 +04:00
|
|
|
/**
|
|
|
|
* disc_dupl_alert - issue node address duplication alert
|
2015-11-19 22:30:47 +03:00
|
|
|
* @b: pointer to bearer detecting duplication
|
2006-10-17 08:44:59 +04:00
|
|
|
* @node_addr: duplicated node address
|
|
|
|
* @media_addr: media address advertised by duplicated node
|
|
|
|
*/
|
2015-11-19 22:30:47 +03:00
|
|
|
static void disc_dupl_alert(struct tipc_bearer *b, u32 node_addr,
|
2006-10-17 08:44:59 +04:00
|
|
|
struct tipc_media_addr *media_addr)
|
|
|
|
{
|
|
|
|
char media_addr_str[64];
|
|
|
|
|
2012-06-29 08:50:23 +04:00
|
|
|
tipc_media_addr_printf(media_addr_str, sizeof(media_addr_str),
|
|
|
|
media_addr);
|
2018-03-22 22:42:50 +03:00
|
|
|
pr_warn("Duplicate %x using %s seen on <%s>\n", node_addr,
|
2015-11-19 22:30:47 +03:00
|
|
|
media_addr_str, b->name);
|
2006-10-17 08:44:59 +04:00
|
|
|
}
|
|
|
|
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
/* tipc_disc_addr_trial(): - handle an address uniqueness trial from peer
|
2018-07-06 21:10:04 +03:00
|
|
|
* Returns true if message should be dropped by caller, i.e., if it is a
|
|
|
|
* trial message or we are inside trial period. Otherwise false.
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
*/
|
2018-03-23 22:47:42 +03:00
|
|
|
static bool tipc_disc_addr_trial_msg(struct tipc_discoverer *d,
|
|
|
|
struct tipc_media_addr *maddr,
|
|
|
|
struct tipc_bearer *b,
|
|
|
|
u32 dst, u32 src,
|
|
|
|
u32 sugg_addr,
|
|
|
|
u8 *peer_id,
|
|
|
|
int mtyp)
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
{
|
|
|
|
struct net *net = d->net;
|
|
|
|
struct tipc_net *tn = tipc_net(net);
|
|
|
|
bool trial = time_before(jiffies, tn->addr_trial_end);
|
|
|
|
u32 self = tipc_own_addr(net);
|
|
|
|
|
|
|
|
if (mtyp == DSC_TRIAL_FAIL_MSG) {
|
|
|
|
if (!trial)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Ignore if somebody else already gave new suggestion */
|
|
|
|
if (dst != tn->trial_addr)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Otherwise update trial address and restart trial period */
|
|
|
|
tn->trial_addr = sugg_addr;
|
|
|
|
msg_set_prevnode(buf_msg(d->skb), sugg_addr);
|
|
|
|
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Apply trial address if we just left trial period */
|
|
|
|
if (!trial && !self) {
|
2021-05-18 05:09:08 +03:00
|
|
|
schedule_work(&tn->work);
|
2018-11-17 00:55:04 +03:00
|
|
|
msg_set_prevnode(buf_msg(d->skb), tn->trial_addr);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
msg_set_type(buf_msg(d->skb), DSC_REQ_MSG);
|
|
|
|
}
|
|
|
|
|
2018-07-06 21:10:04 +03:00
|
|
|
/* Accept regular link requests/responses only after trial period */
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
if (mtyp != DSC_TRIAL_MSG)
|
2018-07-06 21:10:04 +03:00
|
|
|
return trial;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
|
|
|
|
sugg_addr = tipc_node_try_addr(net, peer_id, src);
|
|
|
|
if (sugg_addr)
|
|
|
|
tipc_disc_msg_xmit(net, DSC_TRIAL_FAIL_MSG, src,
|
|
|
|
self, sugg_addr, maddr, b);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2006-01-02 21:04:38 +03:00
|
|
|
/**
|
2014-05-14 13:39:14 +04:00
|
|
|
* tipc_disc_rcv - handle incoming discovery message (request or response)
|
2018-03-22 22:42:46 +03:00
|
|
|
* @net: applicable net namespace
|
|
|
|
* @skb: buffer containing message
|
|
|
|
* @b: bearer that message arrived on
|
2006-01-02 21:04:38 +03:00
|
|
|
*/
|
2015-07-31 01:24:22 +03:00
|
|
|
void tipc_disc_rcv(struct net *net, struct sk_buff *skb,
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_bearer *b)
|
2006-01-02 21:04:38 +03:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_net *tn = tipc_net(net);
|
2015-07-31 01:24:22 +03:00
|
|
|
struct tipc_msg *hdr = buf_msg(skb);
|
2019-12-10 11:21:05 +03:00
|
|
|
u32 pnet_hash = msg_peer_net_hash(hdr);
|
2018-03-22 22:42:46 +03:00
|
|
|
u16 caps = msg_node_capabilities(hdr);
|
tipc: allow closest-first lookup algorithm when legacy address is configured
The removal of an internal structure of the node address has an unwanted
side effect.
- Currently, if a user is sending an anycast message with destination
domain 0, the tipc_namebl_translate() function will use the 'closest-
first' algorithm to first look for a node local destination, and only
when no such is found, will it resort to the cluster global 'round-
robin' lookup algorithm.
- Current users can get around this, and enforce unconditional use of
global round-robin by indicating a destination as Z.0.0 or Z.C.0.
- This option disappears when we make the node address flat, since the
lookup algorithm has no way of recognizing this case. So, as long as
there are node local destinations, the algorithm will always select
one of those, and there is nothing the sender can do to change this.
We solve this by eliminating the 'closest-first' option, which was never
a good idea anyway, for non-legacy users, but only for those. To
distinguish between legacy users and non-legacy users we introduce a new
flag 'legacy_addr_format' in struct tipc_core, to be set when the user
configures a legacy-style Z.C.N node address. Hence, when a legacy user
indicates a zero lookup domain 'closest-first' is selected, and in all
other cases we use 'round-robin'.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:48 +03:00
|
|
|
bool legacy = tn->legacy_addr_format;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
u32 sugg = msg_sugg_node_addr(hdr);
|
2018-03-22 22:42:46 +03:00
|
|
|
u32 signature = msg_node_sig(hdr);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
u8 peer_id[NODE_ID_LEN] = {0,};
|
2018-03-22 22:42:46 +03:00
|
|
|
u32 dst = msg_dest_domain(hdr);
|
2015-07-31 01:24:22 +03:00
|
|
|
u32 net_id = msg_bc_netid(hdr);
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_media_addr maddr;
|
|
|
|
u32 src = msg_prevnode(hdr);
|
2015-07-31 01:24:22 +03:00
|
|
|
u32 mtyp = msg_type(hdr);
|
|
|
|
bool dupl_addr = false;
|
2018-03-22 22:42:46 +03:00
|
|
|
bool respond = false;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
u32 self;
|
2016-06-27 14:34:06 +03:00
|
|
|
int err;
|
2006-01-02 21:04:38 +03:00
|
|
|
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
skb_linearize(skb);
|
|
|
|
hdr = buf_msg(skb);
|
|
|
|
|
|
|
|
if (caps & TIPC_NODE_ID128)
|
|
|
|
memcpy(peer_id, msg_node_id(hdr), NODE_ID_LEN);
|
|
|
|
else
|
|
|
|
sprintf(peer_id, "%x", src);
|
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
err = b->media->msg2addr(b, &maddr, msg_media_addr(hdr));
|
2015-07-31 01:24:22 +03:00
|
|
|
kfree_skb(skb);
|
2018-03-22 22:42:46 +03:00
|
|
|
if (err || maddr.broadcast) {
|
|
|
|
pr_warn_ratelimited("Rcv corrupt discovery message\n");
|
2016-06-27 14:34:06 +03:00
|
|
|
return;
|
2018-03-22 22:42:46 +03:00
|
|
|
}
|
|
|
|
/* Ignore discovery messages from own node */
|
|
|
|
if (!memcmp(&maddr, &b->addr, sizeof(maddr)))
|
2006-01-02 21:04:38 +03:00
|
|
|
return;
|
2018-03-22 22:42:46 +03:00
|
|
|
if (net_id != tn->net_id)
|
2011-10-07 23:48:41 +04:00
|
|
|
return;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
if (tipc_disc_addr_trial_msg(b->disc, &maddr, b, dst,
|
|
|
|
src, sugg, peer_id, mtyp))
|
|
|
|
return;
|
|
|
|
self = tipc_own_addr(net);
|
|
|
|
|
|
|
|
/* Message from somebody using this node's address */
|
2018-03-22 22:42:46 +03:00
|
|
|
if (in_own_node(net, src)) {
|
|
|
|
disc_dupl_alert(b, self, &maddr);
|
2006-01-02 21:04:38 +03:00
|
|
|
return;
|
2006-10-17 08:44:59 +04:00
|
|
|
}
|
tipc: allow closest-first lookup algorithm when legacy address is configured
The removal of an internal structure of the node address has an unwanted
side effect.
- Currently, if a user is sending an anycast message with destination
domain 0, the tipc_namebl_translate() function will use the 'closest-
first' algorithm to first look for a node local destination, and only
when no such is found, will it resort to the cluster global 'round-
robin' lookup algorithm.
- Current users can get around this, and enforce unconditional use of
global round-robin by indicating a destination as Z.0.0 or Z.C.0.
- This option disappears when we make the node address flat, since the
lookup algorithm has no way of recognizing this case. So, as long as
there are node local destinations, the algorithm will always select
one of those, and there is nothing the sender can do to change this.
We solve this by eliminating the 'closest-first' option, which was never
a good idea anyway, for non-legacy users, but only for those. To
distinguish between legacy users and non-legacy users we introduce a new
flag 'legacy_addr_format' in struct tipc_core, to be set when the user
configures a legacy-style Z.C.N node address. Hence, when a legacy user
indicates a zero lookup domain 'closest-first' is selected, and in all
other cases we use 'round-robin'.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:48 +03:00
|
|
|
if (!tipc_in_scope(legacy, dst, self))
|
|
|
|
return;
|
|
|
|
if (!tipc_in_scope(legacy, b->domain, src))
|
|
|
|
return;
|
2019-12-10 11:21:05 +03:00
|
|
|
tipc_node_check_dest(net, src, peer_id, b, caps, signature, pnet_hash,
|
|
|
|
&maddr, &respond, &dupl_addr);
|
2015-07-31 01:24:22 +03:00
|
|
|
if (dupl_addr)
|
2018-03-22 22:42:46 +03:00
|
|
|
disc_dupl_alert(b, src, &maddr);
|
|
|
|
if (!respond)
|
|
|
|
return;
|
|
|
|
if (mtyp != DSC_REQ_MSG)
|
|
|
|
return;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
tipc_disc_msg_xmit(net, DSC_RESP_MSG, src, self, 0, &maddr, b);
|
2006-01-02 21:04:38 +03:00
|
|
|
}
|
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
/* tipc_disc_add_dest - increment set of discovered nodes
|
2006-01-02 21:04:38 +03:00
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
void tipc_disc_add_dest(struct tipc_discoverer *d)
|
2006-01-02 21:04:38 +03:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
spin_lock_bh(&d->lock);
|
|
|
|
d->num_nodes++;
|
|
|
|
spin_unlock_bh(&d->lock);
|
2007-02-09 17:25:21 +03:00
|
|
|
}
|
2006-01-02 21:04:38 +03:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
/* tipc_disc_remove_dest - decrement set of discovered nodes
|
2011-04-22 04:05:25 +04:00
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
void tipc_disc_remove_dest(struct tipc_discoverer *d)
|
2011-04-22 04:05:25 +04:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
int intv, num;
|
2011-04-22 04:05:25 +04:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
spin_lock_bh(&d->lock);
|
|
|
|
d->num_nodes--;
|
|
|
|
num = d->num_nodes;
|
|
|
|
intv = d->timer_intv;
|
|
|
|
if (!num && (intv == TIPC_DISC_INACTIVE || intv > TIPC_DISC_FAST)) {
|
|
|
|
d->timer_intv = TIPC_DISC_INIT;
|
|
|
|
mod_timer(&d->timer, jiffies + d->timer_intv);
|
|
|
|
}
|
|
|
|
spin_unlock_bh(&d->lock);
|
2011-04-22 04:05:25 +04:00
|
|
|
}
|
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
/* tipc_disc_timeout - send a periodic link setup request
|
2006-01-02 21:04:38 +03:00
|
|
|
* Called whenever a link setup request timer associated with a bearer expires.
|
2018-03-22 22:42:46 +03:00
|
|
|
* - Keep doubling time between sent request until limit is reached;
|
|
|
|
* - Hold at fast polling rate if we don't have any associated nodes
|
|
|
|
* - Otherwise hold at slow polling rate
|
2006-01-02 21:04:38 +03:00
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
static void tipc_disc_timeout(struct timer_list *t)
|
2006-01-02 21:04:38 +03:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_discoverer *d = from_timer(d, t, timer);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
struct tipc_net *tn = tipc_net(d->net);
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_media_addr maddr;
|
|
|
|
struct sk_buff *skb = NULL;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
struct net *net = d->net;
|
2018-03-22 22:42:46 +03:00
|
|
|
u32 bearer_id;
|
2011-04-22 05:34:03 +04:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
spin_lock_bh(&d->lock);
|
2006-01-02 21:04:38 +03:00
|
|
|
|
2011-04-22 05:34:03 +04:00
|
|
|
/* Stop searching if only desired node has been found */
|
2018-03-22 22:42:46 +03:00
|
|
|
if (tipc_node(d->domain) && d->num_nodes) {
|
|
|
|
d->timer_intv = TIPC_DISC_INACTIVE;
|
2011-04-22 05:34:03 +04:00
|
|
|
goto exit;
|
2006-01-02 21:04:38 +03:00
|
|
|
}
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
|
2018-11-17 00:55:04 +03:00
|
|
|
/* Did we just leave trial period ? */
|
|
|
|
if (!time_before(jiffies, tn->addr_trial_end) && !tipc_own_addr(net)) {
|
|
|
|
mod_timer(&d->timer, jiffies + TIPC_DISC_INIT);
|
|
|
|
spin_unlock_bh(&d->lock);
|
2021-05-18 05:09:08 +03:00
|
|
|
schedule_work(&tn->work);
|
2018-11-17 00:55:04 +03:00
|
|
|
return;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
}
|
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
/* Adjust timeout interval according to discovery phase */
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
if (time_before(jiffies, tn->addr_trial_end)) {
|
|
|
|
d->timer_intv = TIPC_DISC_INIT;
|
|
|
|
} else {
|
|
|
|
d->timer_intv *= 2;
|
|
|
|
if (d->num_nodes && d->timer_intv > TIPC_DISC_SLOW)
|
|
|
|
d->timer_intv = TIPC_DISC_SLOW;
|
|
|
|
else if (!d->num_nodes && d->timer_intv > TIPC_DISC_FAST)
|
|
|
|
d->timer_intv = TIPC_DISC_FAST;
|
2018-11-17 00:55:04 +03:00
|
|
|
msg_set_type(buf_msg(d->skb), DSC_REQ_MSG);
|
|
|
|
msg_set_prevnode(buf_msg(d->skb), tn->trial_addr);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
}
|
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
mod_timer(&d->timer, jiffies + d->timer_intv);
|
|
|
|
memcpy(&maddr, &d->dest, sizeof(maddr));
|
|
|
|
skb = skb_clone(d->skb, GFP_ATOMIC);
|
|
|
|
bearer_id = d->bearer_id;
|
2011-04-22 05:34:03 +04:00
|
|
|
exit:
|
2018-03-22 22:42:46 +03:00
|
|
|
spin_unlock_bh(&d->lock);
|
|
|
|
if (skb)
|
|
|
|
tipc_bearer_xmit_skb(net, bearer_id, skb, &maddr);
|
2006-01-02 21:04:38 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-21 22:58:26 +04:00
|
|
|
* tipc_disc_create - create object to send periodic link setup requests
|
2015-01-09 10:27:04 +03:00
|
|
|
* @net: the applicable net namespace
|
2015-11-19 22:30:47 +03:00
|
|
|
* @b: ptr to bearer issuing requests
|
2006-01-02 21:04:38 +03:00
|
|
|
* @dest: destination address for request messages
|
2020-07-13 02:15:14 +03:00
|
|
|
* @skb: pointer to created frame
|
2007-02-09 17:25:21 +03:00
|
|
|
*
|
2020-11-29 21:32:48 +03:00
|
|
|
* Return: 0 if successful, otherwise -errno.
|
2006-01-02 21:04:38 +03:00
|
|
|
*/
|
2015-11-19 22:30:47 +03:00
|
|
|
int tipc_disc_create(struct net *net, struct tipc_bearer *b,
|
tipc: eliminate buffer leak in bearer layer
When enabling a bearer we create a 'neigbor discoverer' instance by
calling the function tipc_disc_create() before the bearer is actually
registered in the list of enabled bearers. Because of this, the very
first discovery broadcast message, created by the mentioned function,
is lost, since it cannot find any valid bearer to use. Furthermore,
the used send function, tipc_bearer_xmit_skb() does not free the given
buffer when it cannot find a bearer, resulting in the leak of exactly
one send buffer each time a bearer is enabled.
This commit fixes this problem by introducing two changes:
1) Instead of attemting to send the discovery message directly, we let
tipc_disc_create() return the discovery buffer to the calling
function, tipc_enable_bearer(), so that the latter can send it
when the enabling sequence is finished.
2) In tipc_bearer_xmit_skb(), as well as in the two other transmit
functions at the bearer layer, we now free the indicated buffer or
buffer chain when a valid bearer cannot be found.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-07 17:09:13 +03:00
|
|
|
struct tipc_media_addr *dest, struct sk_buff **skb)
|
2006-01-02 21:04:38 +03:00
|
|
|
{
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
struct tipc_net *tn = tipc_net(net);
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_discoverer *d;
|
2006-01-02 21:04:38 +03:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
d = kmalloc(sizeof(*d), GFP_ATOMIC);
|
|
|
|
if (!d)
|
2011-04-21 22:58:26 +04:00
|
|
|
return -ENOMEM;
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
d->skb = tipc_buf_acquire(MAX_H_SIZE + NODE_ID_LEN, GFP_ATOMIC);
|
2018-03-22 22:42:46 +03:00
|
|
|
if (!d->skb) {
|
|
|
|
kfree(d);
|
2014-04-21 06:55:52 +04:00
|
|
|
return -ENOMEM;
|
2014-04-25 06:44:15 +04:00
|
|
|
}
|
2018-03-22 22:42:46 +03:00
|
|
|
tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
|
tipc: handle collisions of 32-bit node address hash values
When a 32-bit node address is generated from a 128-bit identifier,
there is a risk of collisions which must be discovered and handled.
We do this as follows:
- We don't apply the generated address immediately to the node, but do
instead initiate a 1 sec trial period to allow other cluster members
to discover and handle such collisions.
- During the trial period the node periodically sends out a new type
of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
to all the other nodes in the cluster.
- When a node is receiving such a message, it must check that the
presented 32-bit identifier either is unused, or was used by the very
same peer in a previous session. In both cases it accepts the request
by not responding to it.
- If it finds that the same node has been up before using a different
address, it responds with a DSC_TRIAL_FAIL_MSG containing that
address.
- If it finds that the address has already been taken by some other
node, it generates a new, unused address and returns it to the
requester.
- During the trial period the requesting node must always be prepared
to accept a failure message, i.e., a message where a peer suggests a
different (or equal) address to the one tried. In those cases it
must apply the suggested value as trial address and restart the trial
period.
This algorithm ensures that in the vast majority of cases a node will
have the same address before and after a reboot. If a legacy user
configures the address explicitly, there will be no trial period and
messages, so this protocol addition is completely backwards compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 22:42:51 +03:00
|
|
|
|
|
|
|
/* Do we need an address trial period first ? */
|
|
|
|
if (!tipc_own_addr(net)) {
|
|
|
|
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
|
|
|
|
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
|
|
|
|
}
|
2018-03-22 22:42:46 +03:00
|
|
|
memcpy(&d->dest, dest, sizeof(*dest));
|
|
|
|
d->net = net;
|
|
|
|
d->bearer_id = b->identity;
|
|
|
|
d->domain = b->domain;
|
|
|
|
d->num_nodes = 0;
|
|
|
|
d->timer_intv = TIPC_DISC_INIT;
|
|
|
|
spin_lock_init(&d->lock);
|
|
|
|
timer_setup(&d->timer, tipc_disc_timeout, 0);
|
|
|
|
mod_timer(&d->timer, jiffies + d->timer_intv);
|
|
|
|
b->disc = d;
|
|
|
|
*skb = skb_clone(d->skb, GFP_ATOMIC);
|
2011-04-21 22:58:26 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_disc_delete - destroy object sending periodic link setup requests
|
2020-11-29 21:32:50 +03:00
|
|
|
* @d: ptr to link dest structure
|
2011-04-21 22:58:26 +04:00
|
|
|
*/
|
2018-03-22 22:42:46 +03:00
|
|
|
void tipc_disc_delete(struct tipc_discoverer *d)
|
2011-04-21 22:58:26 +04:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
del_timer_sync(&d->timer);
|
|
|
|
kfree_skb(d->skb);
|
|
|
|
kfree(d);
|
2007-02-09 17:25:21 +03:00
|
|
|
}
|
2014-04-21 06:55:52 +04:00
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_disc_reset - reset object to send periodic link setup requests
|
2015-01-09 10:27:04 +03:00
|
|
|
* @net: the applicable net namespace
|
2015-11-19 22:30:47 +03:00
|
|
|
* @b: ptr to bearer issuing requests
|
2014-04-21 06:55:52 +04:00
|
|
|
*/
|
2015-11-19 22:30:47 +03:00
|
|
|
void tipc_disc_reset(struct net *net, struct tipc_bearer *b)
|
2014-04-21 06:55:52 +04:00
|
|
|
{
|
2018-03-22 22:42:46 +03:00
|
|
|
struct tipc_discoverer *d = b->disc;
|
|
|
|
struct tipc_media_addr maddr;
|
2015-10-22 15:51:44 +03:00
|
|
|
struct sk_buff *skb;
|
2014-04-21 06:55:52 +04:00
|
|
|
|
2018-03-22 22:42:46 +03:00
|
|
|
spin_lock_bh(&d->lock);
|
|
|
|
tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
|
|
|
|
d->net = net;
|
|
|
|
d->bearer_id = b->identity;
|
|
|
|
d->domain = b->domain;
|
|
|
|
d->num_nodes = 0;
|
|
|
|
d->timer_intv = TIPC_DISC_INIT;
|
|
|
|
memcpy(&maddr, &d->dest, sizeof(maddr));
|
|
|
|
mod_timer(&d->timer, jiffies + d->timer_intv);
|
|
|
|
skb = skb_clone(d->skb, GFP_ATOMIC);
|
|
|
|
spin_unlock_bh(&d->lock);
|
2015-10-22 15:51:44 +03:00
|
|
|
if (skb)
|
2018-03-22 22:42:46 +03:00
|
|
|
tipc_bearer_xmit_skb(net, b->identity, skb, &maddr);
|
2014-04-21 06:55:52 +04:00
|
|
|
}
|