2006-01-02 18:04:38 +00:00
|
|
|
/*
|
|
|
|
* net/tipc/link.c: TIPC link code
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
2015-03-13 20:08:08 +00:00
|
|
|
* Copyright (c) 1996-2007, 2012-2015, Ericsson AB
|
2013-06-17 14:54:42 +00:00
|
|
|
* Copyright (c) 2004-2007, 2010-2013, Wind River Systems
|
2006-01-02 18:04:38 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
2006-01-11 12:30:43 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
2006-01-02 18:04:38 +00:00
|
|
|
* 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.
|
2006-01-02 18:04:38 +00:00
|
|
|
*
|
2006-01-11 12:30:43 +00: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 18:04:38 +00:00
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "core.h"
|
tipc: clean up handling of message priorities
Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.
There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.
This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.
In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.
This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-13 20:08:11 +00:00
|
|
|
#include "subscr.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
#include "link.h"
|
2014-11-20 09:29:12 +00:00
|
|
|
#include "bcast.h"
|
2014-05-14 09:39:15 +00:00
|
|
|
#include "socket.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
#include "name_distr.h"
|
|
|
|
#include "discover.h"
|
2014-11-20 09:29:07 +00:00
|
|
|
#include "netlink.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2013-06-17 14:54:48 +00:00
|
|
|
#include <linux/pkt_sched.h>
|
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
/*
|
|
|
|
* Error message prefixes
|
|
|
|
*/
|
|
|
|
static const char *link_co_err = "Link changeover error, ";
|
|
|
|
static const char *link_rst_msg = "Resetting link ";
|
|
|
|
static const char *link_unk_evt = "Unknown link event ";
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2014-11-20 09:29:12 +00:00
|
|
|
static const struct nla_policy tipc_nl_link_policy[TIPC_NLA_LINK_MAX + 1] = {
|
|
|
|
[TIPC_NLA_LINK_UNSPEC] = { .type = NLA_UNSPEC },
|
|
|
|
[TIPC_NLA_LINK_NAME] = {
|
|
|
|
.type = NLA_STRING,
|
|
|
|
.len = TIPC_MAX_LINK_NAME
|
|
|
|
},
|
|
|
|
[TIPC_NLA_LINK_MTU] = { .type = NLA_U32 },
|
|
|
|
[TIPC_NLA_LINK_BROADCAST] = { .type = NLA_FLAG },
|
|
|
|
[TIPC_NLA_LINK_UP] = { .type = NLA_FLAG },
|
|
|
|
[TIPC_NLA_LINK_ACTIVE] = { .type = NLA_FLAG },
|
|
|
|
[TIPC_NLA_LINK_PROP] = { .type = NLA_NESTED },
|
|
|
|
[TIPC_NLA_LINK_STATS] = { .type = NLA_NESTED },
|
|
|
|
[TIPC_NLA_LINK_RX] = { .type = NLA_U32 },
|
|
|
|
[TIPC_NLA_LINK_TX] = { .type = NLA_U32 }
|
|
|
|
};
|
|
|
|
|
2014-11-20 09:29:07 +00:00
|
|
|
/* Properties valid for media, bearar and link */
|
|
|
|
static const struct nla_policy tipc_nl_prop_policy[TIPC_NLA_PROP_MAX + 1] = {
|
|
|
|
[TIPC_NLA_PROP_UNSPEC] = { .type = NLA_UNSPEC },
|
|
|
|
[TIPC_NLA_PROP_PRIO] = { .type = NLA_U32 },
|
|
|
|
[TIPC_NLA_PROP_TOL] = { .type = NLA_U32 },
|
|
|
|
[TIPC_NLA_PROP_WIN] = { .type = NLA_U32 }
|
|
|
|
};
|
|
|
|
|
2008-06-05 00:29:39 +00:00
|
|
|
/*
|
|
|
|
* Out-of-range value for link session numbers
|
|
|
|
*/
|
|
|
|
#define INVALID_SESSION 0x10000
|
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/*
|
|
|
|
* Link state events:
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
|
|
|
#define STARTING_EVT 856384768 /* link processing trigger */
|
|
|
|
#define TRAFFIC_MSG_EVT 560815u /* rx'd ??? */
|
2015-05-14 14:46:16 +00:00
|
|
|
#define SILENCE_EVT 560817u /* timer dicovered silence from peer */
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/*
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
* State value stored in 'failover_pkts'
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
#define FIRST_FAILOVER 0xffffu
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-02-05 13:36:36 +00:00
|
|
|
static void link_handle_out_of_seq_msg(struct tipc_link *link,
|
|
|
|
struct sk_buff *skb);
|
|
|
|
static void tipc_link_proto_rcv(struct tipc_link *link,
|
|
|
|
struct sk_buff *skb);
|
2015-01-09 07:27:00 +00:00
|
|
|
static void link_set_supervision_props(struct tipc_link *l_ptr, u32 tol);
|
2011-12-30 01:58:42 +00:00
|
|
|
static void link_state_event(struct tipc_link *l_ptr, u32 event);
|
|
|
|
static void link_reset_statistics(struct tipc_link *l_ptr);
|
|
|
|
static void link_print(struct tipc_link *l_ptr, const char *str);
|
2014-02-18 08:06:46 +00:00
|
|
|
static void tipc_link_sync_xmit(struct tipc_link *l);
|
|
|
|
static void tipc_link_sync_rcv(struct tipc_node *n, struct sk_buff *buf);
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
static void tipc_link_input(struct tipc_link *l, struct sk_buff *skb);
|
|
|
|
static bool tipc_data_input(struct tipc_link *l, struct sk_buff *skb);
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
static bool tipc_link_failover_rcv(struct tipc_link *l, struct sk_buff **skb);
|
2015-05-14 14:46:16 +00:00
|
|
|
static void link_set_timer(struct tipc_link *link, unsigned long time);
|
2006-01-02 18:04:38 +00:00
|
|
|
/*
|
2006-03-21 06:37:04 +00:00
|
|
|
* Simple link routines
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2006-03-21 06:37:04 +00:00
|
|
|
static unsigned int align(unsigned int i)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
return (i + 3) & ~3u;
|
|
|
|
}
|
|
|
|
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
static void tipc_link_release(struct kref *kref)
|
|
|
|
{
|
|
|
|
kfree(container_of(kref, struct tipc_link, ref));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void tipc_link_get(struct tipc_link *l_ptr)
|
|
|
|
{
|
|
|
|
kref_get(&l_ptr->ref);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void tipc_link_put(struct tipc_link *l_ptr)
|
|
|
|
{
|
|
|
|
kref_put(&l_ptr->ref, tipc_link_release);
|
|
|
|
}
|
|
|
|
|
2015-03-25 16:07:26 +00:00
|
|
|
static struct tipc_link *tipc_parallel_link(struct tipc_link *l)
|
|
|
|
{
|
2015-07-16 20:54:19 +00:00
|
|
|
struct tipc_node *n = l->owner;
|
|
|
|
|
|
|
|
if (node_active_link(n, 0) != l)
|
|
|
|
return node_active_link(n, 0);
|
|
|
|
return node_active_link(n, 1);
|
2015-03-25 16:07:26 +00:00
|
|
|
}
|
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
/*
|
2006-03-21 06:37:04 +00:00
|
|
|
* Simple non-static link routines (i.e. referenced outside this file)
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2011-12-30 01:58:42 +00:00
|
|
|
int tipc_link_is_up(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
if (!l_ptr)
|
|
|
|
return 0;
|
2010-09-22 20:43:57 +00:00
|
|
|
return link_working_working(l_ptr) || link_working_unknown(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
int tipc_link_is_active(struct tipc_link *l)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-07-16 20:54:19 +00:00
|
|
|
struct tipc_node *n = l->owner;
|
|
|
|
|
|
|
|
return (node_active_link(n, 0) == l) || (node_active_link(n, 1) == l);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* link_timeout - handle expiration of link timer
|
|
|
|
* @l_ptr: pointer to link
|
|
|
|
*/
|
2015-01-09 07:27:00 +00:00
|
|
|
static void link_timeout(unsigned long data)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:00 +00:00
|
|
|
struct tipc_link *l_ptr = (struct tipc_link *)data;
|
2014-11-26 03:41:52 +00:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_node_lock(l_ptr->owner);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
/* update counters used in statistical profiling of send traffic */
|
2015-03-13 20:08:10 +00:00
|
|
|
l_ptr->stats.accu_queue_sz += skb_queue_len(&l_ptr->transmq);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.queue_sz_counts++;
|
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
skb = skb_peek(&l_ptr->transmq);
|
2014-11-26 03:41:52 +00:00
|
|
|
if (skb) {
|
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
u32 length = msg_size(msg);
|
|
|
|
|
2009-11-30 00:55:45 +00:00
|
|
|
if ((msg_user(msg) == MSG_FRAGMENTER) &&
|
|
|
|
(msg_type(msg) == FIRST_FRAGMENT)) {
|
2006-01-02 18:04:38 +00:00
|
|
|
length = msg_size(msg_get_wrapped(msg));
|
|
|
|
}
|
|
|
|
if (length) {
|
|
|
|
l_ptr->stats.msg_lengths_total += length;
|
|
|
|
l_ptr->stats.msg_length_counts++;
|
|
|
|
if (length <= 64)
|
|
|
|
l_ptr->stats.msg_length_profile[0]++;
|
|
|
|
else if (length <= 256)
|
|
|
|
l_ptr->stats.msg_length_profile[1]++;
|
|
|
|
else if (length <= 1024)
|
|
|
|
l_ptr->stats.msg_length_profile[2]++;
|
|
|
|
else if (length <= 4096)
|
|
|
|
l_ptr->stats.msg_length_profile[3]++;
|
|
|
|
else if (length <= 16384)
|
|
|
|
l_ptr->stats.msg_length_profile[4]++;
|
|
|
|
else if (length <= 32768)
|
|
|
|
l_ptr->stats.msg_length_profile[5]++;
|
|
|
|
else
|
|
|
|
l_ptr->stats.msg_length_profile[6]++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* do all other link processing performed on a periodic basis */
|
2015-05-14 14:46:16 +00:00
|
|
|
if (l_ptr->silent_intv_cnt || tipc_bclink_acks_missing(l_ptr->owner))
|
|
|
|
link_state_event(l_ptr, SILENCE_EVT);
|
|
|
|
l_ptr->silent_intv_cnt++;
|
2015-03-13 20:08:10 +00:00
|
|
|
if (skb_queue_len(&l_ptr->backlogq))
|
2014-11-26 03:41:48 +00:00
|
|
|
tipc_link_push_packets(l_ptr);
|
2015-05-14 14:46:16 +00:00
|
|
|
link_set_timer(l_ptr, l_ptr->keepalive_intv);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_node_unlock(l_ptr->owner);
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
tipc_link_put(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2015-01-09 07:27:00 +00:00
|
|
|
static void link_set_timer(struct tipc_link *link, unsigned long time)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
if (!mod_timer(&link->timer, jiffies + time))
|
|
|
|
tipc_link_get(link);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2006-01-17 23:38:21 +00:00
|
|
|
* tipc_link_create - create a new link
|
2011-02-28 16:32:27 +00:00
|
|
|
* @n_ptr: pointer to associated node
|
2006-01-02 18:04:38 +00:00
|
|
|
* @b_ptr: pointer to associated bearer
|
|
|
|
* @media_addr: media address to use when sending messages over link
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
2006-01-02 18:04:38 +00:00
|
|
|
* Returns pointer to link.
|
|
|
|
*/
|
2011-12-30 01:58:42 +00:00
|
|
|
struct tipc_link *tipc_link_create(struct tipc_node *n_ptr,
|
tipc: remove 'links' list from tipc_bearer struct
In our ongoing effort to simplify the TIPC locking structure,
we see a need to remove the linked list for tipc_links
in the bearer. This can be explained as follows.
Currently, we have three different ways to access a link,
via three different lists/tables:
1: Via a node hash table:
Used by the time-critical outgoing/incoming data paths.
(e.g. link_send_sections_fast() and tipc_recv_msg() ):
grab net_lock(read)
find node from node hash table
grab node_lock
select link
grab bearer_lock
send_msg()
release bearer_lock
release node lock
release net_lock
2: Via a global linked list for nodes:
Used by configuration commands (link_cmd_set_value())
grab net_lock(read)
find node and link from global node list (using link name)
grab node_lock
update link
release node lock
release net_lock
(Same locking order as above. No problem.)
3: Via the bearer's linked link list:
Used by notifications from interface (e.g. tipc_disable_bearer() )
grab net_lock(write)
grab bearer_lock
get link ptr from bearer's link list
get node from link
grab node_lock
delete link
release node lock
release bearer_lock
release net_lock
(Different order from above, but works because we grab the
outer net_lock in write mode first, excluding all other access.)
The first major goal in our simplification effort is to get rid
of the "big" net_lock, replacing it with rcu-locks when accessing
the node list and node hash array. This will come in a later patch
series.
But to get there we first need to rewrite access methods ##2 and 3,
since removal of net_lock would introduce three major problems:
a) In access method #2, we access the link before taking the
protecting node_lock. This will not work once net_lock is gone,
so we will have to change the access order. We will deal with
this in a later commit in this series, "tipc: add node lock
protection to link found by link_find_link()".
b) When the outer protection from net_lock is gone, taking
bearer_lock and node_lock in opposite order of method 1) and 2)
will become an obvious deadlock hazard. This is fixed in the
commit ("tipc: remove bearer_lock from tipc_bearer struct")
later in this series.
c) Similar to what is described in problem a), access method #3
starts with using a link pointer that is unprotected by node_lock,
in order to via that pointer find the correct node struct and
lock it. Before we remove net_lock, this access order must be
altered. This is what we do with this commit.
We can avoid introducing problem problem c) by even here using the
global node list to find the node, before accessing its links. When
we loop though the node list we use the own bearer identity as search
criteria, thus easily finding the links that are associated to the
resetting/disabling bearer. It should be noted that although this
method is somewhat slower than the current list traversal, it is in
no way time critical. This is only about resetting or deleting links,
something that must be considered relatively infrequent events.
As a bonus, we can get rid of the mutual pointers between links and
bearers. After this commit, pointer dependency go in one direction
only: from the link to the bearer.
This commit pre-empts introduction of problem c) as described above.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:09 +00:00
|
|
|
struct tipc_bearer *b_ptr,
|
2015-07-16 20:54:21 +00:00
|
|
|
const struct tipc_media_addr *media_addr,
|
|
|
|
struct sk_buff_head *inputq,
|
|
|
|
struct sk_buff_head *namedq)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:10 +00:00
|
|
|
struct tipc_net *tn = net_generic(n_ptr->net, tipc_net_id);
|
2011-12-30 01:58:42 +00:00
|
|
|
struct tipc_link *l_ptr;
|
2006-01-02 18:04:38 +00:00
|
|
|
struct tipc_msg *msg;
|
|
|
|
char *if_name;
|
2011-02-28 16:32:27 +00:00
|
|
|
char addr_string[16];
|
|
|
|
u32 peer = n_ptr->addr;
|
|
|
|
|
2014-11-14 17:33:19 +00:00
|
|
|
if (n_ptr->link_cnt >= MAX_BEARERS) {
|
2011-02-28 16:32:27 +00:00
|
|
|
tipc_addr_string_fill(addr_string, n_ptr->addr);
|
2015-05-14 14:46:15 +00:00
|
|
|
pr_err("Cannot establish %uth link to %s. Max %u allowed.\n",
|
|
|
|
n_ptr->link_cnt, addr_string, MAX_BEARERS);
|
2011-02-28 16:32:27 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
if (n_ptr->links[b_ptr->identity].link) {
|
2011-02-28 16:32:27 +00:00
|
|
|
tipc_addr_string_fill(addr_string, n_ptr->addr);
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_err("Attempt to establish second link on <%s> to %s\n",
|
|
|
|
b_ptr->name, addr_string);
|
2011-02-28 16:32:27 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2006-07-21 21:51:30 +00:00
|
|
|
l_ptr = kzalloc(sizeof(*l_ptr), GFP_ATOMIC);
|
2006-01-02 18:04:38 +00:00
|
|
|
if (!l_ptr) {
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("Link creation failed, no memory\n");
|
2006-01-02 18:04:38 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
kref_init(&l_ptr->ref);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->addr = peer;
|
2011-01-07 18:00:11 +00:00
|
|
|
if_name = strchr(b_ptr->name, ':') + 1;
|
2011-04-07 13:28:47 +00:00
|
|
|
sprintf(l_ptr->name, "%u.%u.%u:%s-%u.%u.%u:unknown",
|
2015-01-09 07:27:10 +00:00
|
|
|
tipc_zone(tn->own_addr), tipc_cluster(tn->own_addr),
|
|
|
|
tipc_node(tn->own_addr),
|
2006-01-02 18:04:38 +00:00
|
|
|
if_name,
|
|
|
|
tipc_zone(peer), tipc_cluster(peer), tipc_node(peer));
|
2011-04-07 13:28:47 +00:00
|
|
|
/* note: peer i/f name is updated by reset/activate message */
|
2006-01-02 18:04:38 +00:00
|
|
|
memcpy(&l_ptr->media_addr, media_addr, sizeof(*media_addr));
|
2011-02-28 16:32:27 +00:00
|
|
|
l_ptr->owner = n_ptr;
|
2011-04-07 13:43:27 +00:00
|
|
|
l_ptr->peer_session = INVALID_SESSION;
|
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 02:55:46 +00:00
|
|
|
l_ptr->bearer_id = b_ptr->identity;
|
2011-10-18 15:34:29 +00:00
|
|
|
link_set_supervision_props(l_ptr, b_ptr->tolerance);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = RESET_UNKNOWN;
|
|
|
|
|
|
|
|
l_ptr->pmsg = (struct tipc_msg *)&l_ptr->proto_msg;
|
|
|
|
msg = l_ptr->pmsg;
|
2015-02-05 13:36:36 +00:00
|
|
|
tipc_msg_init(tn->own_addr, msg, LINK_PROTOCOL, RESET_MSG, INT_H_SIZE,
|
2015-01-09 07:27:10 +00:00
|
|
|
l_ptr->addr);
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_size(msg, sizeof(l_ptr->proto_msg));
|
2015-01-09 07:27:12 +00:00
|
|
|
msg_set_session(msg, (tn->random & 0xffff));
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_bearer_id(msg, b_ptr->identity);
|
|
|
|
strcpy((char *)msg_data(msg), if_name);
|
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 02:55:46 +00:00
|
|
|
l_ptr->net_plane = b_ptr->net_plane;
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
l_ptr->advertised_mtu = b_ptr->mtu;
|
|
|
|
l_ptr->mtu = l_ptr->advertised_mtu;
|
tipc: clean up handling of message priorities
Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.
There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.
This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.
In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.
This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-13 20:08:11 +00:00
|
|
|
l_ptr->priority = b_ptr->priority;
|
|
|
|
tipc_link_set_queue_limits(l_ptr, b_ptr->window);
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->snd_nxt = 1;
|
2015-03-13 20:08:10 +00:00
|
|
|
__skb_queue_head_init(&l_ptr->transmq);
|
|
|
|
__skb_queue_head_init(&l_ptr->backlogq);
|
|
|
|
__skb_queue_head_init(&l_ptr->deferdq);
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
skb_queue_head_init(&l_ptr->wakeupq);
|
2015-07-16 20:54:21 +00:00
|
|
|
l_ptr->inputq = inputq;
|
|
|
|
l_ptr->namedq = namedq;
|
|
|
|
skb_queue_head_init(l_ptr->inputq);
|
2006-01-02 18:04:38 +00:00
|
|
|
link_reset_statistics(l_ptr);
|
2011-02-28 16:32:27 +00:00
|
|
|
tipc_node_attach_link(n_ptr, l_ptr);
|
2015-01-09 07:27:00 +00:00
|
|
|
setup_timer(&l_ptr->timer, link_timeout, (unsigned long)l_ptr);
|
2014-01-07 22:02:44 +00:00
|
|
|
link_state_event(l_ptr, STARTING_EVT);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
return l_ptr;
|
|
|
|
}
|
|
|
|
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
/**
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
* tipc_link_delete - Delete a link
|
|
|
|
* @l: link to be deleted
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
*/
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
void tipc_link_delete(struct tipc_link *l)
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
{
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
tipc_link_reset(l);
|
|
|
|
if (del_timer(&l->timer))
|
|
|
|
tipc_link_put(l);
|
|
|
|
l->flags |= LINK_STOPPED;
|
|
|
|
/* Delete link now, or when timer is finished: */
|
|
|
|
tipc_link_reset_fragments(l);
|
|
|
|
tipc_node_detach_link(l->owner, l);
|
|
|
|
tipc_link_put(l);
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
}
|
|
|
|
|
2015-05-14 14:46:11 +00:00
|
|
|
void tipc_link_delete_list(struct net *net, unsigned int bearer_id)
|
2014-02-13 22:29:07 +00:00
|
|
|
{
|
2015-01-09 07:27:05 +00:00
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
struct tipc_link *link;
|
|
|
|
struct tipc_node *node;
|
2014-02-13 22:29:07 +00:00
|
|
|
|
2014-03-27 04:54:37 +00:00
|
|
|
rcu_read_lock();
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
list_for_each_entry_rcu(node, &tn->node_list, list) {
|
|
|
|
tipc_node_lock(node);
|
2015-07-16 20:54:19 +00:00
|
|
|
link = node->links[bearer_id].link;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (link)
|
tipc: add reference count to struct tipc_link
When a bearer is disabled, all pertaining links will be reset and
deleted. However, if there is a second active link towards a killed
link's destination, the delete has to be postponed until the failover
is finished. During this interval, we currently put the link in zombie
mode, i.e., we take it out of traffic, delete its timer, but leave it
attached to the owner node structure until all missing packets have
been received. When this is done, we detach the link from its node
and delete it, assuming that the synchronous timer deletion that was
initiated earlier in a different thread has finished.
This is unsafe, as the failover may finish before del_timer_sync()
has returned in the other thread.
We fix this by adding an atomic reference counter of type kref in
struct tipc_link. The counter keeps track of the references kept
to the link by the owner node and the timer. We then do a conditional
delete, based on the reference counter, both after the failover has
been finished and when the timer expires, if applicable. Whoever
comes last, will actually delete the link. This approach also implies
that we can make the deletion of the timer asynchronous.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:17 +00:00
|
|
|
tipc_link_delete(link);
|
|
|
|
tipc_node_unlock(node);
|
2014-02-13 22:29:07 +00:00
|
|
|
}
|
2014-03-27 04:54:37 +00:00
|
|
|
rcu_read_unlock();
|
2014-02-13 22:29:07 +00:00
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
/**
|
2015-03-25 16:07:25 +00:00
|
|
|
* link_schedule_user - schedule a message sender for wakeup after congestion
|
2014-08-22 22:09:07 +00:00
|
|
|
* @link: congested link
|
2015-03-25 16:07:25 +00:00
|
|
|
* @list: message that was attempted sent
|
2014-08-22 22:09:07 +00:00
|
|
|
* Create pseudo msg to send back to user when congestion abates
|
2015-03-25 16:07:25 +00:00
|
|
|
* Only consumes message if there is an error
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2015-03-25 16:07:25 +00:00
|
|
|
static int link_schedule_user(struct tipc_link *link, struct sk_buff_head *list)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-03-25 16:07:25 +00:00
|
|
|
struct tipc_msg *msg = buf_msg(skb_peek(list));
|
|
|
|
int imp = msg_importance(msg);
|
|
|
|
u32 oport = msg_origport(msg);
|
|
|
|
u32 addr = link_own_addr(link);
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
/* This really cannot happen... */
|
|
|
|
if (unlikely(imp > TIPC_CRITICAL_IMPORTANCE)) {
|
|
|
|
pr_warn("%s<%s>, send queue full", link_rst_msg, link->name);
|
|
|
|
tipc_link_reset(link);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
/* Non-blocking sender: */
|
|
|
|
if (TIPC_SKB_CB(skb_peek(list))->wakeup_pending)
|
|
|
|
return -ELINKCONG;
|
|
|
|
|
|
|
|
/* Create and schedule wakeup pseudo message */
|
|
|
|
skb = tipc_msg_create(SOCK_WAKEUP, 0, INT_H_SIZE, 0,
|
|
|
|
addr, addr, oport, 0, 0);
|
|
|
|
if (!skb)
|
|
|
|
goto err;
|
|
|
|
TIPC_SKB_CB(skb)->chain_sz = skb_queue_len(list);
|
|
|
|
TIPC_SKB_CB(skb)->chain_imp = imp;
|
|
|
|
skb_queue_tail(&link->wakeupq, skb);
|
2014-08-22 22:09:07 +00:00
|
|
|
link->stats.link_congs++;
|
2015-03-25 16:07:25 +00:00
|
|
|
return -ELINKCONG;
|
|
|
|
err:
|
|
|
|
__skb_queue_purge(list);
|
|
|
|
return -ENOBUFS;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2014-08-22 22:09:07 +00:00
|
|
|
/**
|
|
|
|
* link_prepare_wakeup - prepare users for wakeup after congestion
|
|
|
|
* @link: congested link
|
|
|
|
* Move a number of waiting users, as permitted by available space in
|
|
|
|
* the send queue, from link wait queue to node wait queue for wakeup
|
|
|
|
*/
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
void link_prepare_wakeup(struct tipc_link *l)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
int pnd[TIPC_SYSTEM_IMPORTANCE + 1] = {0,};
|
|
|
|
int imp, lim;
|
2014-11-26 03:41:51 +00:00
|
|
|
struct sk_buff *skb, *tmp;
|
2014-08-22 22:09:07 +00:00
|
|
|
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
skb_queue_walk_safe(&l->wakeupq, skb, tmp) {
|
|
|
|
imp = TIPC_SKB_CB(skb)->chain_imp;
|
|
|
|
lim = l->window + l->backlog[imp].limit;
|
|
|
|
pnd[imp] += TIPC_SKB_CB(skb)->chain_sz;
|
|
|
|
if ((pnd[imp] + l->backlog[imp].len) >= lim)
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
skb_unlink(skb, &l->wakeupq);
|
2015-07-16 20:54:21 +00:00
|
|
|
skb_queue_tail(l->inputq, skb);
|
|
|
|
l->owner->inputq = l->inputq;
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
l->owner->action_flags |= TIPC_MSG_EVT;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2006-01-17 23:38:21 +00:00
|
|
|
* tipc_link_reset_fragments - purge link's inbound message fragments queue
|
2006-01-02 18:04:38 +00:00
|
|
|
* @l_ptr: pointer to link
|
|
|
|
*/
|
2011-12-30 01:58:42 +00:00
|
|
|
void tipc_link_reset_fragments(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2014-05-14 09:39:12 +00:00
|
|
|
kfree_skb(l_ptr->reasm_buf);
|
|
|
|
l_ptr->reasm_buf = NULL;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2015-06-28 13:44:44 +00:00
|
|
|
void tipc_link_purge_backlog(struct tipc_link *l)
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
{
|
|
|
|
__skb_queue_purge(&l->backlogq);
|
|
|
|
l->backlog[TIPC_LOW_IMPORTANCE].len = 0;
|
|
|
|
l->backlog[TIPC_MEDIUM_IMPORTANCE].len = 0;
|
|
|
|
l->backlog[TIPC_HIGH_IMPORTANCE].len = 0;
|
|
|
|
l->backlog[TIPC_CRITICAL_IMPORTANCE].len = 0;
|
|
|
|
l->backlog[TIPC_SYSTEM_IMPORTANCE].len = 0;
|
|
|
|
}
|
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/**
|
2014-01-07 22:02:44 +00:00
|
|
|
* tipc_link_purge_queues - purge all pkt queues associated with link
|
2006-01-02 18:04:38 +00:00
|
|
|
* @l_ptr: pointer to link
|
|
|
|
*/
|
2014-01-07 22:02:44 +00:00
|
|
|
void tipc_link_purge_queues(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-03-13 20:08:10 +00:00
|
|
|
__skb_queue_purge(&l_ptr->deferdq);
|
|
|
|
__skb_queue_purge(&l_ptr->transmq);
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
tipc_link_purge_backlog(l_ptr);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_link_reset_fragments(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 01:58:42 +00:00
|
|
|
void tipc_link_reset(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
u32 prev_state = l_ptr->state;
|
2006-06-26 06:52:50 +00:00
|
|
|
int was_active_link = tipc_link_is_active(l_ptr);
|
2014-08-22 22:09:07 +00:00
|
|
|
struct tipc_node *owner = l_ptr->owner;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
struct tipc_link *pl = tipc_parallel_link(l_ptr);
|
2007-02-09 14:25:21 +00:00
|
|
|
|
2008-06-05 00:29:39 +00:00
|
|
|
msg_set_session(l_ptr->pmsg, ((msg_session(l_ptr->pmsg) + 1) & 0xffff));
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2008-06-05 00:29:39 +00:00
|
|
|
/* Link is down, accept any session */
|
|
|
|
l_ptr->peer_session = INVALID_SESSION;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
/* Prepare for renewed mtu size negotiation */
|
|
|
|
l_ptr->mtu = l_ptr->advertised_mtu;
|
2007-02-09 14:25:21 +00:00
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = RESET_UNKNOWN;
|
|
|
|
|
|
|
|
if ((prev_state == RESET_UNKNOWN) || (prev_state == RESET_RESET))
|
|
|
|
return;
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
tipc_node_link_down(l_ptr->owner, l_ptr->bearer_id);
|
2015-01-09 07:27:06 +00:00
|
|
|
tipc_bearer_remove_dest(owner->net, l_ptr->bearer_id, l_ptr->addr);
|
2010-10-12 14:25:58 +00:00
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (was_active_link && tipc_node_is_up(l_ptr->owner) && (pl != l_ptr)) {
|
|
|
|
l_ptr->flags |= LINK_FAILINGOVER;
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->failover_checkpt = l_ptr->rcv_nxt;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
pl->failover_pkts = FIRST_FAILOVER;
|
2015-05-14 14:46:15 +00:00
|
|
|
pl->failover_checkpt = l_ptr->rcv_nxt;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
pl->failover_skb = l_ptr->reasm_buf;
|
|
|
|
} else {
|
|
|
|
kfree_skb(l_ptr->reasm_buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
/* Clean up all queues, except inputq: */
|
2015-03-13 20:08:10 +00:00
|
|
|
__skb_queue_purge(&l_ptr->transmq);
|
|
|
|
__skb_queue_purge(&l_ptr->deferdq);
|
2015-03-09 20:16:22 +00:00
|
|
|
if (!owner->inputq)
|
2015-07-16 20:54:21 +00:00
|
|
|
owner->inputq = l_ptr->inputq;
|
2015-03-09 20:16:22 +00:00
|
|
|
skb_queue_splice_init(&l_ptr->wakeupq, owner->inputq);
|
|
|
|
if (!skb_queue_empty(owner->inputq))
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
owner->action_flags |= TIPC_MSG_EVT;
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
tipc_link_purge_backlog(l_ptr);
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
l_ptr->reasm_buf = NULL;
|
2015-03-13 20:08:10 +00:00
|
|
|
l_ptr->rcv_unacked = 0;
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->snd_nxt = 1;
|
|
|
|
l_ptr->silent_intv_cnt = 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stale_count = 0;
|
|
|
|
link_reset_statistics(l_ptr);
|
|
|
|
}
|
|
|
|
|
2015-01-09 07:27:06 +00:00
|
|
|
static void link_activate(struct tipc_link *link)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:06 +00:00
|
|
|
struct tipc_node *node = link->owner;
|
|
|
|
|
2015-05-14 14:46:15 +00:00
|
|
|
link->rcv_nxt = 1;
|
2015-01-09 07:27:06 +00:00
|
|
|
link->stats.recv_info = 1;
|
2015-05-14 14:46:16 +00:00
|
|
|
link->silent_intv_cnt = 0;
|
2015-07-16 20:54:19 +00:00
|
|
|
tipc_node_link_up(node, link->bearer_id);
|
2015-01-09 07:27:06 +00:00
|
|
|
tipc_bearer_add_dest(node->net, link->bearer_id, link->addr);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* link_state_event - link finite state machine
|
|
|
|
* @l_ptr: pointer to link
|
|
|
|
* @event: state machine event to process
|
|
|
|
*/
|
2012-04-15 05:58:06 +00:00
|
|
|
static void link_state_event(struct tipc_link *l_ptr, unsigned int event)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2011-12-30 01:58:42 +00:00
|
|
|
struct tipc_link *other;
|
2015-05-14 14:46:15 +00:00
|
|
|
unsigned long timer_intv = l_ptr->keepalive_intv;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
tipc: delay delete of link when failover is needed
When a bearer is disabled, all its attached links are deleted.
Ideally, we should do link failover to redundant links on other bearers,
if there are any, in such cases. This would be consistent with current
behavior when a link is reset, but not deleted. However, due to the
complexity involved, and the (wrongly) perceived low demand for this
feature, it was never implemented until now.
We mark the doomed link for deletion with a new flag, but wait until the
failover process is finished before we actually delete it. With the
improved link tunnelling/failover code introduced earlier in this commit
series, it is now easy to identify a spot in the code where the failover
is finished and it is safe to delete the marked link. Moreover, the test
for the flag and the deletion can be done synchronously, and outside the
most time critical data path.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:16 +00:00
|
|
|
if (l_ptr->flags & LINK_STOPPED)
|
|
|
|
return;
|
|
|
|
|
2014-02-13 22:29:08 +00:00
|
|
|
if (!(l_ptr->flags & LINK_STARTED) && (event != STARTING_EVT))
|
2006-01-02 18:04:38 +00:00
|
|
|
return; /* Not yet. */
|
|
|
|
|
2015-05-14 14:46:16 +00:00
|
|
|
if (l_ptr->flags & LINK_FAILINGOVER)
|
2013-12-11 04:45:44 +00:00
|
|
|
return;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
switch (l_ptr->state) {
|
|
|
|
case WORKING_WORKING:
|
|
|
|
switch (event) {
|
|
|
|
case TRAFFIC_MSG_EVT:
|
|
|
|
case ACTIVATE_MSG:
|
2015-05-14 14:46:16 +00:00
|
|
|
l_ptr->silent_intv_cnt = 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
2015-05-14 14:46:16 +00:00
|
|
|
case SILENCE_EVT:
|
|
|
|
if (!l_ptr->silent_intv_cnt) {
|
|
|
|
if (tipc_bclink_acks_missing(l_ptr->owner))
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
l_ptr->state = WORKING_UNKNOWN;
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 1, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case RESET_MSG:
|
2015-01-22 16:10:31 +00:00
|
|
|
pr_debug("%s<%s>, requested by peer\n",
|
|
|
|
link_rst_msg, l_ptr->name);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_link_reset(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = RESET_RESET;
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, ACTIVATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
default:
|
2015-01-22 16:10:31 +00:00
|
|
|
pr_debug("%s%u in WW state\n", link_unk_evt, event);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case WORKING_UNKNOWN:
|
|
|
|
switch (event) {
|
|
|
|
case TRAFFIC_MSG_EVT:
|
|
|
|
case ACTIVATE_MSG:
|
|
|
|
l_ptr->state = WORKING_WORKING;
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->silent_intv_cnt = 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case RESET_MSG:
|
2015-01-22 16:10:31 +00:00
|
|
|
pr_debug("%s<%s>, requested by peer while probing\n",
|
|
|
|
link_rst_msg, l_ptr->name);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_link_reset(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = RESET_RESET;
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, ACTIVATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
2015-05-14 14:46:16 +00:00
|
|
|
case SILENCE_EVT:
|
|
|
|
if (!l_ptr->silent_intv_cnt) {
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = WORKING_WORKING;
|
2015-05-14 14:46:16 +00:00
|
|
|
if (tipc_bclink_acks_missing(l_ptr->owner))
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2015-05-14 14:46:15 +00:00
|
|
|
} else if (l_ptr->silent_intv_cnt <
|
|
|
|
l_ptr->abort_limit) {
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
1, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
} else { /* Link has failed */
|
2015-01-22 16:10:31 +00:00
|
|
|
pr_debug("%s<%s>, peer not responding\n",
|
|
|
|
link_rst_msg, l_ptr->name);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_link_reset(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->state = RESET_UNKNOWN;
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, RESET_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_err("%s%u in WU state\n", link_unk_evt, event);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case RESET_UNKNOWN:
|
|
|
|
switch (event) {
|
|
|
|
case TRAFFIC_MSG_EVT:
|
|
|
|
break;
|
|
|
|
case ACTIVATE_MSG:
|
2015-07-16 20:54:19 +00:00
|
|
|
other = node_active_link(l_ptr->owner, 0);
|
2010-12-31 18:59:27 +00:00
|
|
|
if (other && link_working_unknown(other))
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
l_ptr->state = WORKING_WORKING;
|
|
|
|
link_activate(l_ptr);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 1, 0, 0, 0);
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
if (l_ptr->owner->working_links == 1)
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_sync_xmit(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case RESET_MSG:
|
|
|
|
l_ptr->state = RESET_RESET;
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, ACTIVATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
1, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case STARTING_EVT:
|
2014-02-13 22:29:08 +00:00
|
|
|
l_ptr->flags |= LINK_STARTED;
|
2015-05-14 14:46:15 +00:00
|
|
|
link_set_timer(l_ptr, timer_intv);
|
tipc: separate link starting event from link timeout event
When a new link instance is created, it is trigged to start by
sending it a TIPC_STARTING_EVT, whereafter a regular link
reset is applied to it.
The starting event is codewise treated as a timeout event, and prompts
a link RESET message to be sent to the peer node, carrying a link
session identifier. The later link_reset() call nudges this session
identifier, whereafter all subsequent RESET messages will be sent out
with the new identifier. The latter session number overrides the former,
causing the peer to unconditionally accept it irrespective of its
current working state.
We don't think that this causes any problem, but it is not in accordance
with the protocol spec, and may cause confusion when debugging TIPC
sessions.
To avoid this, we make the starting event distinct from the
subsequent timeout events, by not allowing the former to send
out any RESET message. This eliminates the described problem.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-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>
2015-02-03 13:59:20 +00:00
|
|
|
break;
|
2015-05-14 14:46:16 +00:00
|
|
|
case SILENCE_EVT:
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, RESET_MSG, 0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
default:
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_err("%s%u in RU state\n", link_unk_evt, event);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case RESET_RESET:
|
|
|
|
switch (event) {
|
|
|
|
case TRAFFIC_MSG_EVT:
|
|
|
|
case ACTIVATE_MSG:
|
2015-07-16 20:54:19 +00:00
|
|
|
other = node_active_link(l_ptr->owner, 0);
|
2010-12-31 18:59:27 +00:00
|
|
|
if (other && link_working_unknown(other))
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
l_ptr->state = WORKING_WORKING;
|
|
|
|
link_activate(l_ptr);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 1, 0, 0, 0);
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
if (l_ptr->owner->working_links == 1)
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_sync_xmit(l_ptr);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case RESET_MSG:
|
|
|
|
break;
|
2015-05-14 14:46:16 +00:00
|
|
|
case SILENCE_EVT:
|
2014-02-18 08:06:46 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, ACTIVATE_MSG,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
0, 0, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
default:
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_err("%s%u in RR state\n", link_unk_evt, event);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_err("Unknown link state %u/%u\n", l_ptr->state, event);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
/**
|
2014-07-17 00:41:03 +00:00
|
|
|
* __tipc_link_xmit(): same as tipc_link_xmit, but destlink is known & locked
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
* @link: link to use
|
2014-11-26 03:41:55 +00:00
|
|
|
* @list: chain of buffers containing message
|
|
|
|
*
|
2015-03-25 16:07:25 +00:00
|
|
|
* Consumes the buffer chain, except when returning -ELINKCONG,
|
|
|
|
* since the caller then may want to make more send attempts.
|
|
|
|
* Returns 0 if success, or errno: -ELINKCONG, -EMSGSIZE or -ENOBUFS
|
|
|
|
* Messages at TIPC_SYSTEM_IMPORTANCE are always accepted
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
*/
|
2015-01-09 07:27:06 +00:00
|
|
|
int __tipc_link_xmit(struct net *net, struct tipc_link *link,
|
|
|
|
struct sk_buff_head *list)
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
{
|
2014-11-26 03:41:55 +00:00
|
|
|
struct tipc_msg *msg = buf_msg(skb_peek(list));
|
2015-03-13 20:08:10 +00:00
|
|
|
unsigned int maxwin = link->window;
|
tipc: improve link congestion algorithm
The link congestion algorithm used until now implies two problems.
- It is too generous towards lower-level messages in situations of high
load by giving "absolute" bandwidth guarantees to the different
priority levels. LOW traffic is guaranteed 10%, MEDIUM is guaranted
20%, HIGH is guaranteed 30%, and CRITICAL is guaranteed 40% of the
available bandwidth. But, in the absence of higher level traffic, the
ratio between two distinct levels becomes unreasonable. E.g. if there
is only LOW and MEDIUM traffic on a system, the former is guaranteed
1/3 of the bandwidth, and the latter 2/3. This again means that if
there is e.g. one LOW user and 10 MEDIUM users, the former will have
33.3% of the bandwidth, and the others will have to compete for the
remainder, i.e. each will end up with 6.7% of the capacity.
- Packets of type MSG_BUNDLER are created at SYSTEM importance level,
but only after the packets bundled into it have passed the congestion
test for their own respective levels. Since bundled packets don't
result in incrementing the level counter for their own importance,
only occasionally for the SYSTEM level counter, they do in practice
obtain SYSTEM level importance. Hence, the current implementation
provides a gap in the congestion algorithm that in the worst case
may lead to a link reset.
We now refine the congestion algorithm as follows:
- A message is accepted to the link backlog only if its own level
counter, and all superior level counters, permit it.
- The importance of a created bundle packet is set according to its
contents. A bundle packet created from messges at levels LOW to
CRITICAL is given importance level CRITICAL, while a bundle created
from a SYSTEM level message is given importance SYSTEM. In the latter
case only subsequent SYSTEM level messages are allowed to be bundled
into it.
This solves the first problem described above, by making the bandwidth
guarantee relative to the total number of users at all levels; only
the upper limit for each level remains absolute. In the example
described above, the single LOW user would use 1/11th of the bandwidth,
the same as each of the ten MEDIUM users, but he still has the same
guarantee against starvation as the latter ones.
The fix also solves the second problem. If the CRITICAL level is filled
up by bundle packets of that level, no lower level packets will be
accepted any more.
Suggested-by: Gergely Kiss <gergely.kiss@ericsson.com>
Reviewed-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>
2015-05-14 14:46:17 +00:00
|
|
|
unsigned int i, imp = msg_importance(msg);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
uint mtu = link->mtu;
|
2015-05-14 14:46:15 +00:00
|
|
|
u16 ack = mod(link->rcv_nxt - 1);
|
|
|
|
u16 seqno = link->snd_nxt;
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 bc_last_in = link->owner->bclink.last_in;
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
struct tipc_media_addr *addr = &link->media_addr;
|
2015-03-13 20:08:10 +00:00
|
|
|
struct sk_buff_head *transmq = &link->transmq;
|
|
|
|
struct sk_buff_head *backlogq = &link->backlogq;
|
2015-05-14 14:46:18 +00:00
|
|
|
struct sk_buff *skb, *bskb;
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
|
tipc: improve link congestion algorithm
The link congestion algorithm used until now implies two problems.
- It is too generous towards lower-level messages in situations of high
load by giving "absolute" bandwidth guarantees to the different
priority levels. LOW traffic is guaranteed 10%, MEDIUM is guaranted
20%, HIGH is guaranteed 30%, and CRITICAL is guaranteed 40% of the
available bandwidth. But, in the absence of higher level traffic, the
ratio between two distinct levels becomes unreasonable. E.g. if there
is only LOW and MEDIUM traffic on a system, the former is guaranteed
1/3 of the bandwidth, and the latter 2/3. This again means that if
there is e.g. one LOW user and 10 MEDIUM users, the former will have
33.3% of the bandwidth, and the others will have to compete for the
remainder, i.e. each will end up with 6.7% of the capacity.
- Packets of type MSG_BUNDLER are created at SYSTEM importance level,
but only after the packets bundled into it have passed the congestion
test for their own respective levels. Since bundled packets don't
result in incrementing the level counter for their own importance,
only occasionally for the SYSTEM level counter, they do in practice
obtain SYSTEM level importance. Hence, the current implementation
provides a gap in the congestion algorithm that in the worst case
may lead to a link reset.
We now refine the congestion algorithm as follows:
- A message is accepted to the link backlog only if its own level
counter, and all superior level counters, permit it.
- The importance of a created bundle packet is set according to its
contents. A bundle packet created from messges at levels LOW to
CRITICAL is given importance level CRITICAL, while a bundle created
from a SYSTEM level message is given importance SYSTEM. In the latter
case only subsequent SYSTEM level messages are allowed to be bundled
into it.
This solves the first problem described above, by making the bandwidth
guarantee relative to the total number of users at all levels; only
the upper limit for each level remains absolute. In the example
described above, the single LOW user would use 1/11th of the bandwidth,
the same as each of the ten MEDIUM users, but he still has the same
guarantee against starvation as the latter ones.
The fix also solves the second problem. If the CRITICAL level is filled
up by bundle packets of that level, no lower level packets will be
accepted any more.
Suggested-by: Gergely Kiss <gergely.kiss@ericsson.com>
Reviewed-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>
2015-05-14 14:46:17 +00:00
|
|
|
/* Match msg importance against this and all higher backlog limits: */
|
|
|
|
for (i = imp; i <= TIPC_SYSTEM_IMPORTANCE; i++) {
|
|
|
|
if (unlikely(link->backlog[i].len >= link->backlog[i].limit))
|
|
|
|
return link_schedule_user(link, list);
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
if (unlikely(msg_size(msg) > mtu)) {
|
2014-11-26 03:41:55 +00:00
|
|
|
__skb_queue_purge(list);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
return -EMSGSIZE;
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
/* Prepare each packet for sending, and add to relevant queue: */
|
2015-05-14 14:46:18 +00:00
|
|
|
while (skb_queue_len(list)) {
|
|
|
|
skb = skb_peek(list);
|
2014-11-26 03:41:52 +00:00
|
|
|
msg = buf_msg(skb);
|
2015-03-13 20:08:10 +00:00
|
|
|
msg_set_seqno(msg, seqno);
|
|
|
|
msg_set_ack(msg, ack);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
msg_set_bcast_ack(msg, bc_last_in);
|
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
if (likely(skb_queue_len(transmq) < maxwin)) {
|
2015-05-14 14:46:18 +00:00
|
|
|
__skb_dequeue(list);
|
2015-03-13 20:08:10 +00:00
|
|
|
__skb_queue_tail(transmq, skb);
|
|
|
|
tipc_bearer_send(net, link->bearer_id, skb, addr);
|
|
|
|
link->rcv_unacked = 0;
|
|
|
|
seqno++;
|
|
|
|
continue;
|
|
|
|
}
|
2015-05-14 14:46:18 +00:00
|
|
|
if (tipc_msg_bundle(skb_peek_tail(backlogq), msg, mtu)) {
|
|
|
|
kfree_skb(__skb_dequeue(list));
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
link->stats.sent_bundled++;
|
|
|
|
continue;
|
2015-03-13 20:08:10 +00:00
|
|
|
}
|
2015-05-14 14:46:18 +00:00
|
|
|
if (tipc_msg_make_bundle(&bskb, msg, mtu, link->addr)) {
|
|
|
|
kfree_skb(__skb_dequeue(list));
|
|
|
|
__skb_queue_tail(backlogq, bskb);
|
|
|
|
link->backlog[msg_importance(buf_msg(bskb))].len++;
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
link->stats.sent_bundled++;
|
|
|
|
link->stats.sent_bundles++;
|
2015-05-14 14:46:18 +00:00
|
|
|
continue;
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
}
|
2015-05-14 14:46:18 +00:00
|
|
|
link->backlog[imp].len += skb_queue_len(list);
|
|
|
|
skb_queue_splice_tail_init(list, backlogq);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
}
|
2015-05-14 14:46:15 +00:00
|
|
|
link->snd_nxt = seqno;
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-26 03:41:55 +00:00
|
|
|
static void skb2list(struct sk_buff *skb, struct sk_buff_head *list)
|
|
|
|
{
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
skb_queue_head_init(list);
|
2014-11-26 03:41:55 +00:00
|
|
|
__skb_queue_tail(list, skb);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __tipc_link_xmit_skb(struct tipc_link *link, struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
struct sk_buff_head head;
|
|
|
|
|
|
|
|
skb2list(skb, &head);
|
2015-01-09 07:27:06 +00:00
|
|
|
return __tipc_link_xmit(link->owner->net, link, &head);
|
2014-11-26 03:41:55 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 16:07:25 +00:00
|
|
|
/* tipc_link_xmit_skb(): send single buffer to destination
|
|
|
|
* Buffers sent via this functon are generally TIPC_SYSTEM_IMPORTANCE
|
|
|
|
* messages, which will not be rejected
|
|
|
|
* The only exception is datagram messages rerouted after secondary
|
|
|
|
* lookup, which are rare and safe to dispose of anyway.
|
|
|
|
* TODO: Return real return value, and let callers use
|
|
|
|
* tipc_wait_for_sendpkt() where applicable
|
|
|
|
*/
|
2015-01-09 07:27:05 +00:00
|
|
|
int tipc_link_xmit_skb(struct net *net, struct sk_buff *skb, u32 dnode,
|
|
|
|
u32 selector)
|
2014-11-26 03:41:55 +00:00
|
|
|
{
|
|
|
|
struct sk_buff_head head;
|
2015-03-25 16:07:25 +00:00
|
|
|
int rc;
|
2014-11-26 03:41:55 +00:00
|
|
|
|
|
|
|
skb2list(skb, &head);
|
2015-03-25 16:07:25 +00:00
|
|
|
rc = tipc_link_xmit(net, &head, dnode, selector);
|
|
|
|
if (rc == -ELINKCONG)
|
|
|
|
kfree_skb(skb);
|
|
|
|
return 0;
|
2014-11-26 03:41:55 +00:00
|
|
|
}
|
|
|
|
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
/**
|
2014-07-17 00:41:03 +00:00
|
|
|
* tipc_link_xmit() is the general link level function for message sending
|
2015-01-09 07:27:05 +00:00
|
|
|
* @net: the applicable net namespace
|
2014-11-26 03:41:55 +00:00
|
|
|
* @list: chain of buffers containing message
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
* @dsz: amount of user data to be sent
|
|
|
|
* @dnode: address of destination node
|
|
|
|
* @selector: a number used for deterministic link selection
|
|
|
|
* Consumes the buffer chain, except when returning -ELINKCONG
|
|
|
|
* Returns 0 if success, otherwise errno: -ELINKCONG,-EHOSTUNREACH,-EMSGSIZE
|
|
|
|
*/
|
2015-01-09 07:27:05 +00:00
|
|
|
int tipc_link_xmit(struct net *net, struct sk_buff_head *list, u32 dnode,
|
|
|
|
u32 selector)
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
{
|
|
|
|
struct tipc_link *link = NULL;
|
|
|
|
struct tipc_node *node;
|
|
|
|
int rc = -EHOSTUNREACH;
|
|
|
|
|
2015-01-09 07:27:05 +00:00
|
|
|
node = tipc_node_find(net, dnode);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
if (node) {
|
|
|
|
tipc_node_lock(node);
|
2015-07-16 20:54:19 +00:00
|
|
|
link = node_active_link(node, selector & 1);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
if (link)
|
2015-01-09 07:27:06 +00:00
|
|
|
rc = __tipc_link_xmit(net, link, list);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
tipc_node_unlock(node);
|
2015-03-26 10:10:24 +00:00
|
|
|
tipc_node_put(node);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
}
|
|
|
|
if (link)
|
|
|
|
return rc;
|
|
|
|
|
2015-03-19 08:02:18 +00:00
|
|
|
if (likely(in_own_node(net, dnode))) {
|
|
|
|
tipc_sk_rcv(net, list);
|
|
|
|
return 0;
|
|
|
|
}
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
__skb_queue_purge(list);
|
tipc: introduce send functions for chained buffers in link
The current link implementation provides several different transmit
functions, depending on the characteristics of the message to be
sent: if it is an iovec or an sk_buff, if it needs fragmentation or
not, if the caller holds the node_lock or not. The permutation of
these options gives us an unwanted amount of unnecessarily complex
code.
As a first step towards simplifying the send path for all messages,
we introduce two new send functions at link level, tipc_link_xmit2()
and __tipc_link_xmit2(). The former looks up a link to the message
destination, and if one is found, it grabs the node lock and calls
the second function, which works exclusively inside the node lock
protection. If no link is found, and the destination is on the same
node, it delivers the message directly to the local destination
socket.
The new functions take a buffer chain where all packet headers are
already prepared, and the correct MTU has been used. These two
functions will later replace all other link-level transmit functions.
The functions are not backwards compatible, so we have added them
as new functions with temporary names. They are tested, but have no
users yet. Those will be added later in this series.
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:32 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
/*
|
2014-02-18 08:06:46 +00:00
|
|
|
* tipc_link_sync_xmit - synchronize broadcast link endpoints.
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
*
|
|
|
|
* Give a newly added peer node the sequence number where it should
|
|
|
|
* start receiving and acking broadcast packets.
|
|
|
|
*
|
|
|
|
* Called with node locked
|
|
|
|
*/
|
2014-07-17 00:40:59 +00:00
|
|
|
static void tipc_link_sync_xmit(struct tipc_link *link)
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
{
|
2014-11-26 03:41:55 +00:00
|
|
|
struct sk_buff *skb;
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
struct tipc_msg *msg;
|
|
|
|
|
2014-11-26 03:41:55 +00:00
|
|
|
skb = tipc_buf_acquire(INT_H_SIZE);
|
|
|
|
if (!skb)
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
return;
|
|
|
|
|
2014-11-26 03:41:55 +00:00
|
|
|
msg = buf_msg(skb);
|
2015-02-05 13:36:36 +00:00
|
|
|
tipc_msg_init(link_own_addr(link), msg, BCAST_PROTOCOL, STATE_MSG,
|
2015-01-09 07:27:10 +00:00
|
|
|
INT_H_SIZE, link->addr);
|
2014-07-17 00:40:59 +00:00
|
|
|
msg_set_last_bcast(msg, link->owner->bclink.acked);
|
2014-11-26 03:41:55 +00:00
|
|
|
__tipc_link_xmit_skb(link, skb);
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-02-18 08:06:46 +00:00
|
|
|
* tipc_link_sync_rcv - synchronize broadcast link endpoints.
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
* Receive the sequence number where we should start receiving and
|
|
|
|
* acking broadcast packets from a newly added peer node, and open
|
|
|
|
* up for reception of such packets.
|
|
|
|
*
|
|
|
|
* Called with node locked
|
|
|
|
*/
|
2014-02-18 08:06:46 +00:00
|
|
|
static void tipc_link_sync_rcv(struct tipc_node *n, struct sk_buff *buf)
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 05:51:31 +00:00
|
|
|
{
|
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
|
|
|
|
|
|
|
n->bclink.last_sent = n->bclink.last_in = msg_last_bcast(msg);
|
|
|
|
n->bclink.recv_permitted = true;
|
|
|
|
kfree_skb(buf);
|
|
|
|
}
|
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/*
|
2014-11-26 03:41:48 +00:00
|
|
|
* tipc_link_push_packets - push unsent packets to bearer
|
|
|
|
*
|
|
|
|
* Push out the unsent messages of a link where congestion
|
|
|
|
* has abated. Node is locked.
|
|
|
|
*
|
|
|
|
* Called with node locked
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2015-03-13 20:08:10 +00:00
|
|
|
void tipc_link_push_packets(struct tipc_link *link)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-03-13 20:08:10 +00:00
|
|
|
struct sk_buff *skb;
|
2014-11-26 03:41:48 +00:00
|
|
|
struct tipc_msg *msg;
|
2015-05-14 14:46:18 +00:00
|
|
|
u16 seqno = link->snd_nxt;
|
2015-05-14 14:46:15 +00:00
|
|
|
u16 ack = mod(link->rcv_nxt - 1);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
while (skb_queue_len(&link->transmq) < link->window) {
|
|
|
|
skb = __skb_dequeue(&link->backlogq);
|
|
|
|
if (!skb)
|
2014-11-26 03:41:48 +00:00
|
|
|
break;
|
2015-03-13 20:08:10 +00:00
|
|
|
msg = buf_msg(skb);
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
link->backlog[msg_importance(msg)].len--;
|
2015-03-13 20:08:10 +00:00
|
|
|
msg_set_ack(msg, ack);
|
2015-05-14 14:46:18 +00:00
|
|
|
msg_set_seqno(msg, seqno);
|
|
|
|
seqno = mod(seqno + 1);
|
2015-03-13 20:08:10 +00:00
|
|
|
msg_set_bcast_ack(msg, link->owner->bclink.last_in);
|
|
|
|
link->rcv_unacked = 0;
|
|
|
|
__skb_queue_tail(&link->transmq, skb);
|
|
|
|
tipc_bearer_send(link->owner->net, link->bearer_id,
|
|
|
|
skb, &link->media_addr);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2015-05-14 14:46:18 +00:00
|
|
|
link->snd_nxt = seqno;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2014-05-05 00:56:17 +00:00
|
|
|
void tipc_link_reset_all(struct tipc_node *node)
|
2006-06-26 06:40:01 +00:00
|
|
|
{
|
|
|
|
char addr_string[16];
|
|
|
|
u32 i;
|
|
|
|
|
2014-05-05 00:56:17 +00:00
|
|
|
tipc_node_lock(node);
|
2006-06-26 06:40:01 +00:00
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("Resetting all links to %s\n",
|
2014-05-05 00:56:17 +00:00
|
|
|
tipc_addr_string_fill(addr_string, node->addr));
|
2006-06-26 06:40:01 +00:00
|
|
|
|
|
|
|
for (i = 0; i < MAX_BEARERS; i++) {
|
2015-07-16 20:54:19 +00:00
|
|
|
if (node->links[i].link) {
|
|
|
|
link_print(node->links[i].link, "Resetting link\n");
|
|
|
|
tipc_link_reset(node->links[i].link);
|
2006-06-26 06:40:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-05 00:56:17 +00:00
|
|
|
tipc_node_unlock(node);
|
2006-06-26 06:40:01 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 01:58:42 +00:00
|
|
|
static void link_retransmit_failure(struct tipc_link *l_ptr,
|
2013-06-17 14:54:47 +00:00
|
|
|
struct sk_buff *buf)
|
2006-06-26 06:40:01 +00:00
|
|
|
{
|
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
2015-01-09 07:27:07 +00:00
|
|
|
struct net *net = l_ptr->owner->net;
|
2006-06-26 06:40:01 +00:00
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("Retransmission failure on link <%s>\n", l_ptr->name);
|
2006-06-26 06:40:01 +00:00
|
|
|
|
|
|
|
if (l_ptr->addr) {
|
|
|
|
/* Handle failure on standard link */
|
2010-12-31 18:59:27 +00:00
|
|
|
link_print(l_ptr, "Resetting link\n");
|
2006-06-26 06:40:01 +00:00
|
|
|
tipc_link_reset(l_ptr);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/* Handle failure on broadcast link */
|
2008-09-03 06:38:32 +00:00
|
|
|
struct tipc_node *n_ptr;
|
2006-06-26 06:40:01 +00:00
|
|
|
char addr_string[16];
|
|
|
|
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_info("Msg seq number: %u, ", msg_seqno(msg));
|
|
|
|
pr_cont("Outstanding acks: %lu\n",
|
|
|
|
(unsigned long) TIPC_SKB_CB(buf)->handle);
|
2006-10-03 23:25:34 +00:00
|
|
|
|
2015-01-09 07:27:07 +00:00
|
|
|
n_ptr = tipc_bclink_retransmit_to(net);
|
2006-06-26 06:40:01 +00:00
|
|
|
|
2010-05-11 14:30:12 +00:00
|
|
|
tipc_addr_string_fill(addr_string, n_ptr->addr);
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_info("Broadcast link info for %s\n", addr_string);
|
2012-11-16 05:51:30 +00:00
|
|
|
pr_info("Reception permitted: %d, Acked: %u\n",
|
|
|
|
n_ptr->bclink.recv_permitted,
|
2012-06-29 04:16:37 +00:00
|
|
|
n_ptr->bclink.acked);
|
|
|
|
pr_info("Last in: %u, Oos state: %u, Last sent: %u\n",
|
|
|
|
n_ptr->bclink.last_in,
|
|
|
|
n_ptr->bclink.oos_state,
|
|
|
|
n_ptr->bclink.last_sent);
|
2006-06-26 06:40:01 +00:00
|
|
|
|
tipc: fix potential deadlock when all links are reset
[ 60.988363] ======================================================
[ 60.988754] [ INFO: possible circular locking dependency detected ]
[ 60.989152] 3.19.0+ #194 Not tainted
[ 60.989377] -------------------------------------------------------
[ 60.989781] swapper/3/0 is trying to acquire lock:
[ 60.990079] (&(&n_ptr->lock)->rlock){+.-...}, at: [<ffffffffa0006dca>] tipc_link_retransmit+0x1aa/0x240 [tipc]
[ 60.990743]
[ 60.990743] but task is already holding lock:
[ 60.991106] (&(&bclink->lock)->rlock){+.-...}, at: [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
[ 60.991738]
[ 60.991738] which lock already depends on the new lock.
[ 60.991738]
[ 60.992174]
[ 60.992174] the existing dependency chain (in reverse order) is:
[ 60.992174]
-> #1 (&(&bclink->lock)->rlock){+.-...}:
[ 60.992174] [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
[ 60.992174] [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
[ 60.992174] [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
[ 60.992174] [<ffffffffa0000f57>] tipc_bclink_add_node+0x97/0xf0 [tipc]
[ 60.992174] [<ffffffffa0011815>] tipc_node_link_up+0xf5/0x110 [tipc]
[ 60.992174] [<ffffffffa0007783>] link_state_event+0x2b3/0x4f0 [tipc]
[ 60.992174] [<ffffffffa00193c0>] tipc_link_proto_rcv+0x24c/0x418 [tipc]
[ 60.992174] [<ffffffffa0008857>] tipc_rcv+0x827/0xac0 [tipc]
[ 60.992174] [<ffffffffa0002ca3>] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
[ 60.992174] [<ffffffff81646e66>] __netif_receive_skb_core+0x746/0x980
[ 60.992174] [<ffffffff816470c1>] __netif_receive_skb+0x21/0x70
[ 60.992174] [<ffffffff81647295>] netif_receive_skb_internal+0x35/0x130
[ 60.992174] [<ffffffff81648218>] napi_gro_receive+0x158/0x1d0
[ 60.992174] [<ffffffff81559e05>] e1000_clean_rx_irq+0x155/0x490
[ 60.992174] [<ffffffff8155c1b7>] e1000_clean+0x267/0x990
[ 60.992174] [<ffffffff81647b60>] net_rx_action+0x150/0x360
[ 60.992174] [<ffffffff8105ec43>] __do_softirq+0x123/0x360
[ 60.992174] [<ffffffff8105f12e>] irq_exit+0x8e/0xb0
[ 60.992174] [<ffffffff8179f9f5>] do_IRQ+0x65/0x110
[ 60.992174] [<ffffffff8179da6f>] ret_from_intr+0x0/0x13
[ 60.992174] [<ffffffff8100de9f>] arch_cpu_idle+0xf/0x20
[ 60.992174] [<ffffffff8109dfa6>] cpu_startup_entry+0x2f6/0x3f0
[ 60.992174] [<ffffffff81033cda>] start_secondary+0x13a/0x150
[ 60.992174]
-> #0 (&(&n_ptr->lock)->rlock){+.-...}:
[ 60.992174] [<ffffffff810a8f7d>] __lock_acquire+0x163d/0x1ca0
[ 60.992174] [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
[ 60.992174] [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
[ 60.992174] [<ffffffffa0006dca>] tipc_link_retransmit+0x1aa/0x240 [tipc]
[ 60.992174] [<ffffffffa0001e11>] tipc_bclink_rcv+0x611/0x640 [tipc]
[ 60.992174] [<ffffffffa0008646>] tipc_rcv+0x616/0xac0 [tipc]
[ 60.992174] [<ffffffffa0002ca3>] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
[ 60.992174] [<ffffffff81646e66>] __netif_receive_skb_core+0x746/0x980
[ 60.992174] [<ffffffff816470c1>] __netif_receive_skb+0x21/0x70
[ 60.992174] [<ffffffff81647295>] netif_receive_skb_internal+0x35/0x130
[ 60.992174] [<ffffffff81648218>] napi_gro_receive+0x158/0x1d0
[ 60.992174] [<ffffffff81559e05>] e1000_clean_rx_irq+0x155/0x490
[ 60.992174] [<ffffffff8155c1b7>] e1000_clean+0x267/0x990
[ 60.992174] [<ffffffff81647b60>] net_rx_action+0x150/0x360
[ 60.992174] [<ffffffff8105ec43>] __do_softirq+0x123/0x360
[ 60.992174] [<ffffffff8105f12e>] irq_exit+0x8e/0xb0
[ 60.992174] [<ffffffff8179f9f5>] do_IRQ+0x65/0x110
[ 60.992174] [<ffffffff8179da6f>] ret_from_intr+0x0/0x13
[ 60.992174] [<ffffffff8100de9f>] arch_cpu_idle+0xf/0x20
[ 60.992174] [<ffffffff8109dfa6>] cpu_startup_entry+0x2f6/0x3f0
[ 60.992174] [<ffffffff81033cda>] start_secondary+0x13a/0x150
[ 60.992174]
[ 60.992174] other info that might help us debug this:
[ 60.992174]
[ 60.992174] Possible unsafe locking scenario:
[ 60.992174]
[ 60.992174] CPU0 CPU1
[ 60.992174] ---- ----
[ 60.992174] lock(&(&bclink->lock)->rlock);
[ 60.992174] lock(&(&n_ptr->lock)->rlock);
[ 60.992174] lock(&(&bclink->lock)->rlock);
[ 60.992174] lock(&(&n_ptr->lock)->rlock);
[ 60.992174]
[ 60.992174] *** DEADLOCK ***
[ 60.992174]
[ 60.992174] 3 locks held by swapper/3/0:
[ 60.992174] #0: (rcu_read_lock){......}, at: [<ffffffff81646791>] __netif_receive_skb_core+0x71/0x980
[ 60.992174] #1: (rcu_read_lock){......}, at: [<ffffffffa0002c35>] tipc_l2_rcv_msg+0x5/0xd0 [tipc]
[ 60.992174] #2: (&(&bclink->lock)->rlock){+.-...}, at: [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
[ 60.992174]
The correct the sequence of grabbing n_ptr->lock and bclink->lock
should be that the former is first held and the latter is then taken,
which exactly happened on CPU1. But especially when the retransmission
of broadcast link is failed, bclink->lock is first held in
tipc_bclink_rcv(), and n_ptr->lock is taken in link_retransmit_failure()
called by tipc_link_retransmit() subsequently, which is demonstrated on
CPU0. As a result, deadlock occurs.
If the order of holding the two locks happening on CPU0 is reversed, the
deadlock risk will be relieved. Therefore, the node lock taken in
link_retransmit_failure() originally is moved to tipc_bclink_rcv()
so that it's obtained before bclink lock. But the precondition of
the adjustment of node lock is that responding to bclink reset event
must be moved from tipc_bclink_unlock() to tipc_node_unlock().
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-26 10:10:23 +00:00
|
|
|
n_ptr->action_flags |= TIPC_BCAST_RESET;
|
2006-06-26 06:40:01 +00:00
|
|
|
l_ptr->stale_count = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-11-26 03:41:52 +00:00
|
|
|
void tipc_link_retransmit(struct tipc_link *l_ptr, struct sk_buff *skb,
|
2006-01-17 23:38:21 +00:00
|
|
|
u32 retransmits)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
struct tipc_msg *msg;
|
|
|
|
|
2014-11-26 03:41:52 +00:00
|
|
|
if (!skb)
|
2006-06-26 06:40:01 +00:00
|
|
|
return;
|
|
|
|
|
2014-11-26 03:41:52 +00:00
|
|
|
msg = buf_msg(skb);
|
2007-02-09 14:25:21 +00:00
|
|
|
|
tipc: remove interface state mirroring in bearer
struct 'tipc_bearer' is a generic representation of the underlying
media type, and exists in a one-to-one relationship to each interface
TIPC is using. The struct contains a 'blocked' flag that mirrors the
operational and execution state of the represented interface, and is
updated through notification calls from the latter. The users of
tipc_bearer are checking this flag before each attempt to send a
packet via the interface.
This state mirroring serves no purpose in the current code base. TIPC
links will not discover a media failure any faster through this
mechanism, and in reality the flag only adds overhead at packet
sending and reception.
Furthermore, the fact that the flag needs to be protected by a spinlock
aggregated into tipc_bearer has turned out to cause a serious and
completely unnecessary deadlock problem.
CPU0 CPU1
---- ----
Time 0: bearer_disable() link_timeout()
Time 1: spin_lock_bh(&b_ptr->lock) tipc_link_push_queue()
Time 2: tipc_link_delete() tipc_bearer_blocked(b_ptr)
Time 3: k_cancel_timer(&req->timer) spin_lock_bh(&b_ptr->lock)
Time 4: del_timer_sync(&req->timer)
I.e., del_timer_sync() on CPU0 never returns, because the timer handler
on CPU1 is waiting for the bearer lock.
We eliminate the 'blocked' flag from struct tipc_bearer, along with all
tests on this flag. This not only resolves the deadlock, but also
simplifies and speeds up the data path execution of TIPC. It also fits
well into our ongoing effort to make the locking policy simpler and
more manageable.
An effect of this change is that we can get rid of functions such as
tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
We replace the latter with a new function, tipc_reset_bearer(), which
resets all links associated to the bearer immediately after an
interface goes down.
A user might notice one slight change in link behaviour after this
change. When an interface goes down, (e.g. through a NETDEV_DOWN
event) all attached links will be reset immediately, instead of
leaving it to each link to detect the failure through a timer-driven
mechanism. We consider this an improvement, and see no obvious risks
with the new behavior.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <Paul.Gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 15:08:00 +00:00
|
|
|
/* Detect repeated retransmit failures */
|
2015-05-14 14:46:15 +00:00
|
|
|
if (l_ptr->last_retransm == msg_seqno(msg)) {
|
tipc: remove interface state mirroring in bearer
struct 'tipc_bearer' is a generic representation of the underlying
media type, and exists in a one-to-one relationship to each interface
TIPC is using. The struct contains a 'blocked' flag that mirrors the
operational and execution state of the represented interface, and is
updated through notification calls from the latter. The users of
tipc_bearer are checking this flag before each attempt to send a
packet via the interface.
This state mirroring serves no purpose in the current code base. TIPC
links will not discover a media failure any faster through this
mechanism, and in reality the flag only adds overhead at packet
sending and reception.
Furthermore, the fact that the flag needs to be protected by a spinlock
aggregated into tipc_bearer has turned out to cause a serious and
completely unnecessary deadlock problem.
CPU0 CPU1
---- ----
Time 0: bearer_disable() link_timeout()
Time 1: spin_lock_bh(&b_ptr->lock) tipc_link_push_queue()
Time 2: tipc_link_delete() tipc_bearer_blocked(b_ptr)
Time 3: k_cancel_timer(&req->timer) spin_lock_bh(&b_ptr->lock)
Time 4: del_timer_sync(&req->timer)
I.e., del_timer_sync() on CPU0 never returns, because the timer handler
on CPU1 is waiting for the bearer lock.
We eliminate the 'blocked' flag from struct tipc_bearer, along with all
tests on this flag. This not only resolves the deadlock, but also
simplifies and speeds up the data path execution of TIPC. It also fits
well into our ongoing effort to make the locking policy simpler and
more manageable.
An effect of this change is that we can get rid of functions such as
tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
We replace the latter with a new function, tipc_reset_bearer(), which
resets all links associated to the bearer immediately after an
interface goes down.
A user might notice one slight change in link behaviour after this
change. When an interface goes down, (e.g. through a NETDEV_DOWN
event) all attached links will be reset immediately, instead of
leaving it to each link to detect the failure through a timer-driven
mechanism. We consider this an improvement, and see no obvious risks
with the new behavior.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <Paul.Gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 15:08:00 +00:00
|
|
|
if (++l_ptr->stale_count > 100) {
|
2014-11-26 03:41:52 +00:00
|
|
|
link_retransmit_failure(l_ptr, skb);
|
tipc: remove interface state mirroring in bearer
struct 'tipc_bearer' is a generic representation of the underlying
media type, and exists in a one-to-one relationship to each interface
TIPC is using. The struct contains a 'blocked' flag that mirrors the
operational and execution state of the represented interface, and is
updated through notification calls from the latter. The users of
tipc_bearer are checking this flag before each attempt to send a
packet via the interface.
This state mirroring serves no purpose in the current code base. TIPC
links will not discover a media failure any faster through this
mechanism, and in reality the flag only adds overhead at packet
sending and reception.
Furthermore, the fact that the flag needs to be protected by a spinlock
aggregated into tipc_bearer has turned out to cause a serious and
completely unnecessary deadlock problem.
CPU0 CPU1
---- ----
Time 0: bearer_disable() link_timeout()
Time 1: spin_lock_bh(&b_ptr->lock) tipc_link_push_queue()
Time 2: tipc_link_delete() tipc_bearer_blocked(b_ptr)
Time 3: k_cancel_timer(&req->timer) spin_lock_bh(&b_ptr->lock)
Time 4: del_timer_sync(&req->timer)
I.e., del_timer_sync() on CPU0 never returns, because the timer handler
on CPU1 is waiting for the bearer lock.
We eliminate the 'blocked' flag from struct tipc_bearer, along with all
tests on this flag. This not only resolves the deadlock, but also
simplifies and speeds up the data path execution of TIPC. It also fits
well into our ongoing effort to make the locking policy simpler and
more manageable.
An effect of this change is that we can get rid of functions such as
tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
We replace the latter with a new function, tipc_reset_bearer(), which
resets all links associated to the bearer immediately after an
interface goes down.
A user might notice one slight change in link behaviour after this
change. When an interface goes down, (e.g. through a NETDEV_DOWN
event) all attached links will be reset immediately, instead of
leaving it to each link to detect the failure through a timer-driven
mechanism. We consider this an improvement, and see no obvious risks
with the new behavior.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <Paul.Gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 15:08:00 +00:00
|
|
|
return;
|
2006-06-26 06:40:01 +00:00
|
|
|
}
|
|
|
|
} else {
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->last_retransm = msg_seqno(msg);
|
tipc: remove interface state mirroring in bearer
struct 'tipc_bearer' is a generic representation of the underlying
media type, and exists in a one-to-one relationship to each interface
TIPC is using. The struct contains a 'blocked' flag that mirrors the
operational and execution state of the represented interface, and is
updated through notification calls from the latter. The users of
tipc_bearer are checking this flag before each attempt to send a
packet via the interface.
This state mirroring serves no purpose in the current code base. TIPC
links will not discover a media failure any faster through this
mechanism, and in reality the flag only adds overhead at packet
sending and reception.
Furthermore, the fact that the flag needs to be protected by a spinlock
aggregated into tipc_bearer has turned out to cause a serious and
completely unnecessary deadlock problem.
CPU0 CPU1
---- ----
Time 0: bearer_disable() link_timeout()
Time 1: spin_lock_bh(&b_ptr->lock) tipc_link_push_queue()
Time 2: tipc_link_delete() tipc_bearer_blocked(b_ptr)
Time 3: k_cancel_timer(&req->timer) spin_lock_bh(&b_ptr->lock)
Time 4: del_timer_sync(&req->timer)
I.e., del_timer_sync() on CPU0 never returns, because the timer handler
on CPU1 is waiting for the bearer lock.
We eliminate the 'blocked' flag from struct tipc_bearer, along with all
tests on this flag. This not only resolves the deadlock, but also
simplifies and speeds up the data path execution of TIPC. It also fits
well into our ongoing effort to make the locking policy simpler and
more manageable.
An effect of this change is that we can get rid of functions such as
tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
We replace the latter with a new function, tipc_reset_bearer(), which
resets all links associated to the bearer immediately after an
interface goes down.
A user might notice one slight change in link behaviour after this
change. When an interface goes down, (e.g. through a NETDEV_DOWN
event) all attached links will be reset immediately, instead of
leaving it to each link to detect the failure through a timer-driven
mechanism. We consider this an improvement, and see no obvious risks
with the new behavior.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <Paul.Gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 15:08:00 +00:00
|
|
|
l_ptr->stale_count = 1;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2006-06-26 06:40:01 +00:00
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_queue_walk_from(&l_ptr->transmq, skb) {
|
|
|
|
if (!retransmits)
|
2014-11-26 03:41:52 +00:00
|
|
|
break;
|
|
|
|
msg = buf_msg(skb);
|
2015-05-14 14:46:15 +00:00
|
|
|
msg_set_ack(msg, mod(l_ptr->rcv_nxt - 1));
|
2007-02-09 14:25:21 +00:00
|
|
|
msg_set_bcast_ack(msg, l_ptr->owner->bclink.last_in);
|
2015-01-09 07:27:06 +00:00
|
|
|
tipc_bearer_send(l_ptr->owner->net, l_ptr->bearer_id, skb,
|
|
|
|
&l_ptr->media_addr);
|
2012-11-15 03:34:45 +00:00
|
|
|
retransmits--;
|
|
|
|
l_ptr->stats.retransmitted++;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-25 16:07:26 +00:00
|
|
|
/* link_synch(): check if all packets arrived before the synch
|
|
|
|
* point have been consumed
|
|
|
|
* Returns true if the parallel links are synched, otherwise false
|
|
|
|
*/
|
|
|
|
static bool link_synch(struct tipc_link *l)
|
|
|
|
{
|
|
|
|
unsigned int post_synch;
|
|
|
|
struct tipc_link *pl;
|
|
|
|
|
|
|
|
pl = tipc_parallel_link(l);
|
|
|
|
if (pl == l)
|
|
|
|
goto synched;
|
|
|
|
|
|
|
|
/* Was last pre-synch packet added to input queue ? */
|
2015-05-14 14:46:15 +00:00
|
|
|
if (less_eq(pl->rcv_nxt, l->synch_point))
|
2015-03-25 16:07:26 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Is it still in the input queue ? */
|
2015-05-14 14:46:15 +00:00
|
|
|
post_synch = mod(pl->rcv_nxt - l->synch_point) - 1;
|
2015-07-16 20:54:21 +00:00
|
|
|
if (skb_queue_len(pl->inputq) > post_synch)
|
2015-03-25 16:07:26 +00:00
|
|
|
return false;
|
|
|
|
synched:
|
|
|
|
l->flags &= ~LINK_SYNCHING;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-11-26 03:41:54 +00:00
|
|
|
static void link_retrieve_defq(struct tipc_link *link,
|
|
|
|
struct sk_buff_head *list)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 seq_no;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
if (skb_queue_empty(&link->deferdq))
|
2014-11-26 03:41:54 +00:00
|
|
|
return;
|
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
seq_no = buf_seqno(skb_peek(&link->deferdq));
|
2015-05-14 14:46:15 +00:00
|
|
|
if (seq_no == link->rcv_nxt)
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_queue_splice_tail_init(&link->deferdq, list);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2010-08-17 11:00:07 +00:00
|
|
|
/**
|
2014-01-07 22:02:41 +00:00
|
|
|
* tipc_rcv - process TIPC packets/messages arriving from off-node
|
2015-01-09 07:27:05 +00:00
|
|
|
* @net: the applicable net namespace
|
2014-11-26 03:41:54 +00:00
|
|
|
* @skb: TIPC packet
|
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 02:55:46 +00:00
|
|
|
* @b_ptr: pointer to bearer message arrived on
|
2010-08-17 11:00:07 +00:00
|
|
|
*
|
|
|
|
* Invoked with no locks held. Bearer pointer must point to a valid bearer
|
|
|
|
* structure (i.e. cannot be NULL), but bearer can be inactive.
|
|
|
|
*/
|
2015-01-09 07:27:04 +00:00
|
|
|
void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:10 +00:00
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
2014-11-26 03:41:54 +00:00
|
|
|
struct sk_buff_head head;
|
|
|
|
struct tipc_node *n_ptr;
|
|
|
|
struct tipc_link *l_ptr;
|
|
|
|
struct sk_buff *skb1, *tmp;
|
|
|
|
struct tipc_msg *msg;
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 seq_no;
|
|
|
|
u16 ackd;
|
2014-11-26 03:41:54 +00:00
|
|
|
u32 released;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2014-11-26 03:41:55 +00:00
|
|
|
skb2list(skb, &head);
|
2008-04-16 02:04:54 +00:00
|
|
|
|
2014-11-26 03:41:54 +00:00
|
|
|
while ((skb = __skb_dequeue(&head))) {
|
2008-04-16 02:04:54 +00:00
|
|
|
/* Ensure message is well-formed */
|
2015-03-13 20:08:06 +00:00
|
|
|
if (unlikely(!tipc_msg_validate(skb)))
|
2013-10-30 03:26:57 +00:00
|
|
|
goto discard;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2008-04-16 02:04:54 +00:00
|
|
|
/* Handle arrival of a non-unicast link message */
|
2014-11-26 03:41:54 +00:00
|
|
|
msg = buf_msg(skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
if (unlikely(msg_non_seq(msg))) {
|
2008-06-05 00:32:35 +00:00
|
|
|
if (msg_user(msg) == LINK_CONFIG)
|
2015-01-09 07:27:04 +00:00
|
|
|
tipc_disc_rcv(net, skb, b_ptr);
|
2008-06-05 00:32:35 +00:00
|
|
|
else
|
2015-01-09 07:27:04 +00:00
|
|
|
tipc_bclink_rcv(net, skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
continue;
|
|
|
|
}
|
2007-02-09 14:25:21 +00:00
|
|
|
|
2011-04-05 19:15:04 +00:00
|
|
|
/* Discard unicast link messages destined for another node */
|
2006-06-26 06:39:31 +00:00
|
|
|
if (unlikely(!msg_short(msg) &&
|
2015-01-09 07:27:10 +00:00
|
|
|
(msg_destnode(msg) != tn->own_addr)))
|
2013-10-30 03:26:57 +00:00
|
|
|
goto discard;
|
2007-02-09 14:25:21 +00:00
|
|
|
|
2010-08-17 11:00:16 +00:00
|
|
|
/* Locate neighboring node that sent message */
|
2015-01-09 07:27:05 +00:00
|
|
|
n_ptr = tipc_node_find(net, msg_prevnode(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
if (unlikely(!n_ptr))
|
2013-10-30 03:26:57 +00:00
|
|
|
goto discard;
|
2008-04-16 02:04:54 +00:00
|
|
|
|
2015-03-26 10:10:24 +00:00
|
|
|
tipc_node_lock(n_ptr);
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
/* Locate unicast link endpoint that should handle message */
|
2015-07-16 20:54:19 +00:00
|
|
|
l_ptr = n_ptr->links[b_ptr->identity].link;
|
2013-10-30 03:26:57 +00:00
|
|
|
if (unlikely(!l_ptr))
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
goto unlock;
|
2010-08-17 11:00:16 +00:00
|
|
|
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
/* Verify that communication with node is currently allowed */
|
2014-05-08 00:54:39 +00:00
|
|
|
if ((n_ptr->action_flags & TIPC_WAIT_PEER_LINKS_DOWN) &&
|
2014-05-05 00:56:11 +00:00
|
|
|
msg_user(msg) == LINK_PROTOCOL &&
|
|
|
|
(msg_type(msg) == RESET_MSG ||
|
|
|
|
msg_type(msg) == ACTIVATE_MSG) &&
|
|
|
|
!msg_redundant_link(msg))
|
2014-05-08 00:54:39 +00:00
|
|
|
n_ptr->action_flags &= ~TIPC_WAIT_PEER_LINKS_DOWN;
|
2014-05-05 00:56:11 +00:00
|
|
|
|
|
|
|
if (tipc_node_blocked(n_ptr))
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
goto unlock;
|
2008-04-16 02:04:54 +00:00
|
|
|
|
|
|
|
/* Validate message sequence number info */
|
|
|
|
seq_no = msg_seqno(msg);
|
|
|
|
ackd = msg_ack(msg);
|
|
|
|
|
|
|
|
/* Release acked messages */
|
2015-03-13 20:08:09 +00:00
|
|
|
if (unlikely(n_ptr->bclink.acked != msg_bcast_ack(msg)))
|
2011-10-24 19:26:24 +00:00
|
|
|
tipc_bclink_acknowledge(n_ptr, msg_bcast_ack(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2014-11-26 03:41:52 +00:00
|
|
|
released = 0;
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_queue_walk_safe(&l_ptr->transmq, skb1, tmp) {
|
|
|
|
if (more(buf_seqno(skb1), ackd))
|
2014-11-26 03:41:52 +00:00
|
|
|
break;
|
2015-03-13 20:08:10 +00:00
|
|
|
__skb_unlink(skb1, &l_ptr->transmq);
|
2014-11-26 03:41:52 +00:00
|
|
|
kfree_skb(skb1);
|
|
|
|
released = 1;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2008-04-16 02:04:54 +00:00
|
|
|
|
|
|
|
/* Try sending any messages link endpoint has pending */
|
2015-03-13 20:08:10 +00:00
|
|
|
if (unlikely(skb_queue_len(&l_ptr->backlogq)))
|
2014-11-26 03:41:48 +00:00
|
|
|
tipc_link_push_packets(l_ptr);
|
2014-02-13 22:29:15 +00:00
|
|
|
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
if (released && !skb_queue_empty(&l_ptr->wakeupq))
|
2014-08-22 22:09:07 +00:00
|
|
|
link_prepare_wakeup(l_ptr);
|
2014-02-13 22:29:15 +00:00
|
|
|
|
|
|
|
/* Process the incoming packet */
|
2013-10-30 03:26:57 +00:00
|
|
|
if (unlikely(!link_working_working(l_ptr))) {
|
|
|
|
if (msg_user(msg) == LINK_PROTOCOL) {
|
2015-02-05 13:36:36 +00:00
|
|
|
tipc_link_proto_rcv(l_ptr, skb);
|
2014-11-26 03:41:54 +00:00
|
|
|
link_retrieve_defq(l_ptr, &head);
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
skb = NULL;
|
|
|
|
goto unlock;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2013-10-30 03:26:57 +00:00
|
|
|
|
|
|
|
/* Traffic message. Conditionally activate link */
|
|
|
|
link_state_event(l_ptr, TRAFFIC_MSG_EVT);
|
|
|
|
|
|
|
|
if (link_working_working(l_ptr)) {
|
|
|
|
/* Re-insert buffer in front of queue */
|
2014-11-26 03:41:54 +00:00
|
|
|
__skb_queue_head(&head, skb);
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
skb = NULL;
|
|
|
|
goto unlock;
|
2013-10-30 03:26:57 +00:00
|
|
|
}
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
goto unlock;
|
2013-10-30 03:26:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Link is now in state WORKING_WORKING */
|
2015-05-14 14:46:15 +00:00
|
|
|
if (unlikely(seq_no != l_ptr->rcv_nxt)) {
|
2015-02-05 13:36:36 +00:00
|
|
|
link_handle_out_of_seq_msg(l_ptr, skb);
|
2014-11-26 03:41:54 +00:00
|
|
|
link_retrieve_defq(l_ptr, &head);
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
skb = NULL;
|
|
|
|
goto unlock;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2015-05-14 14:46:16 +00:00
|
|
|
l_ptr->silent_intv_cnt = 0;
|
|
|
|
|
2015-03-25 16:07:26 +00:00
|
|
|
/* Synchronize with parallel link if applicable */
|
|
|
|
if (unlikely((l_ptr->flags & LINK_SYNCHING) && !msg_dup(msg))) {
|
2015-04-28 20:59:04 +00:00
|
|
|
if (!link_synch(l_ptr))
|
|
|
|
goto unlock;
|
2015-03-25 16:07:26 +00:00
|
|
|
}
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->rcv_nxt++;
|
2015-03-13 20:08:10 +00:00
|
|
|
if (unlikely(!skb_queue_empty(&l_ptr->deferdq)))
|
2014-11-26 03:41:54 +00:00
|
|
|
link_retrieve_defq(l_ptr, &head);
|
2015-03-13 20:08:10 +00:00
|
|
|
if (unlikely(++l_ptr->rcv_unacked >= TIPC_MIN_LINK_WIN)) {
|
2014-07-01 08:22:41 +00:00
|
|
|
l_ptr->stats.sent_acks++;
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 0, 0, 0, 0);
|
2014-07-01 08:22:41 +00:00
|
|
|
}
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
tipc_link_input(l_ptr, skb);
|
|
|
|
skb = NULL;
|
|
|
|
unlock:
|
2013-10-30 03:26:57 +00:00
|
|
|
tipc_node_unlock(n_ptr);
|
2015-03-26 10:10:24 +00:00
|
|
|
tipc_node_put(n_ptr);
|
2013-10-30 03:26:57 +00:00
|
|
|
discard:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
if (unlikely(skb))
|
|
|
|
kfree_skb(skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
/* tipc_data_input - deliver data and name distr msgs to upper layer
|
2014-07-01 08:22:40 +00:00
|
|
|
*
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
* Consumes buffer if message is of right type
|
2014-07-01 08:22:40 +00:00
|
|
|
* Node lock must be held
|
|
|
|
*/
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
static bool tipc_data_input(struct tipc_link *link, struct sk_buff *skb)
|
2014-07-01 08:22:40 +00:00
|
|
|
{
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
struct tipc_node *node = link->owner;
|
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
|
|
|
u32 dport = msg_destport(msg);
|
2014-07-01 08:22:40 +00:00
|
|
|
|
|
|
|
switch (msg_user(msg)) {
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
case TIPC_LOW_IMPORTANCE:
|
|
|
|
case TIPC_MEDIUM_IMPORTANCE:
|
|
|
|
case TIPC_HIGH_IMPORTANCE:
|
|
|
|
case TIPC_CRITICAL_IMPORTANCE:
|
|
|
|
case CONN_MANAGER:
|
2015-07-16 20:54:21 +00:00
|
|
|
if (tipc_skb_queue_tail(link->inputq, skb, dport)) {
|
|
|
|
node->inputq = link->inputq;
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
node->action_flags |= TIPC_MSG_EVT;
|
2014-07-01 08:22:40 +00:00
|
|
|
}
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
return true;
|
2014-07-01 08:22:40 +00:00
|
|
|
case NAME_DISTRIBUTOR:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
node->bclink.recv_permitted = true;
|
2015-07-16 20:54:21 +00:00
|
|
|
node->namedq = link->namedq;
|
|
|
|
skb_queue_tail(link->namedq, skb);
|
|
|
|
if (skb_queue_len(link->namedq) == 1)
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
node->action_flags |= TIPC_NAMED_MSG_EVT;
|
|
|
|
return true;
|
|
|
|
case MSG_BUNDLER:
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
case TUNNEL_PROTOCOL:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
case MSG_FRAGMENTER:
|
2014-07-01 08:22:40 +00:00
|
|
|
case BCAST_PROTOCOL:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
return false;
|
2014-07-01 08:22:40 +00:00
|
|
|
default:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
pr_warn("Dropping received illegal msg type\n");
|
|
|
|
kfree_skb(skb);
|
|
|
|
return false;
|
|
|
|
};
|
2014-07-01 08:22:40 +00:00
|
|
|
}
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
|
|
|
|
/* tipc_link_input - process packet that has passed link protocol check
|
|
|
|
*
|
|
|
|
* Consumes buffer
|
|
|
|
* Node lock must be held
|
2014-07-01 08:22:40 +00:00
|
|
|
*/
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
static void tipc_link_input(struct tipc_link *link, struct sk_buff *skb)
|
2014-07-01 08:22:40 +00:00
|
|
|
{
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
struct tipc_node *node = link->owner;
|
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
|
|
|
struct sk_buff *iskb;
|
|
|
|
int pos = 0;
|
|
|
|
|
|
|
|
if (likely(tipc_data_input(link, skb)))
|
|
|
|
return;
|
2014-07-01 08:22:40 +00:00
|
|
|
|
|
|
|
switch (msg_user(msg)) {
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
case TUNNEL_PROTOCOL:
|
2015-03-25 16:07:26 +00:00
|
|
|
if (msg_dup(msg)) {
|
|
|
|
link->flags |= LINK_SYNCHING;
|
|
|
|
link->synch_point = msg_seqno(msg_get_wrapped(msg));
|
2015-04-02 13:33:00 +00:00
|
|
|
kfree_skb(skb);
|
|
|
|
break;
|
2015-03-25 16:07:26 +00:00
|
|
|
}
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (!tipc_link_failover_rcv(link, &skb))
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
break;
|
|
|
|
if (msg_user(buf_msg(skb)) != MSG_BUNDLER) {
|
|
|
|
tipc_data_input(link, skb);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MSG_BUNDLER:
|
|
|
|
link->stats.recv_bundles++;
|
|
|
|
link->stats.recv_bundled += msg_msgcnt(msg);
|
|
|
|
|
|
|
|
while (tipc_msg_extract(skb, &iskb, &pos))
|
|
|
|
tipc_data_input(link, iskb);
|
2014-07-01 08:22:40 +00:00
|
|
|
break;
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
case MSG_FRAGMENTER:
|
|
|
|
link->stats.recv_fragments++;
|
|
|
|
if (tipc_buf_append(&link->reasm_buf, &skb)) {
|
|
|
|
link->stats.recv_fragmented++;
|
|
|
|
tipc_data_input(link, skb);
|
|
|
|
} else if (!link->reasm_buf) {
|
|
|
|
tipc_link_reset(link);
|
|
|
|
}
|
2014-07-01 08:22:40 +00:00
|
|
|
break;
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
case BCAST_PROTOCOL:
|
|
|
|
tipc_link_sync_rcv(node, skb);
|
2014-07-01 08:22:40 +00:00
|
|
|
break;
|
|
|
|
default:
|
tipc: resolve race problem at unicast message reception
TIPC handles message cardinality and sequencing at the link layer,
before passing messages upwards to the destination sockets. During the
upcall from link to socket no locks are held. It is therefore possible,
and we see it happen occasionally, that messages arriving in different
threads and delivered in sequence still bypass each other before they
reach the destination socket. This must not happen, since it violates
the sequentiality guarantee.
We solve this by adding a new input buffer queue to the link structure.
Arriving messages are added safely to the tail of that queue by the
link, while the head of the queue is consumed, also safely, by the
receiving socket. Sequentiality is secured per socket by only allowing
buffers to be dequeued inside the socket lock. Since there may be multiple
simultaneous readers of the queue, we use a 'filter' parameter to reduce
the risk that they peek the same buffer from the queue, hence also
reducing the risk of contention on the receiving socket locks.
This solves the sequentiality problem, and seems to cause no measurable
performance degradation.
A nice side effect of this change is that lock handling in the functions
tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
will enable future simplifications of those functions.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05 13:36:41 +00:00
|
|
|
break;
|
|
|
|
};
|
2014-07-01 08:22:40 +00:00
|
|
|
}
|
|
|
|
|
2012-07-10 10:55:09 +00:00
|
|
|
/**
|
2011-10-25 14:44:35 +00:00
|
|
|
* tipc_link_defer_pkt - Add out-of-sequence message to deferred reception queue
|
|
|
|
*
|
|
|
|
* Returns increase in queue length (i.e. 0 or 1)
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2014-11-26 03:41:53 +00:00
|
|
|
u32 tipc_link_defer_pkt(struct sk_buff_head *list, struct sk_buff *skb)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2014-11-26 03:41:53 +00:00
|
|
|
struct sk_buff *skb1;
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 seq_no = buf_seqno(skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
/* Empty queue ? */
|
2014-11-26 03:41:53 +00:00
|
|
|
if (skb_queue_empty(list)) {
|
|
|
|
__skb_queue_tail(list, skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Last ? */
|
2014-11-26 03:41:53 +00:00
|
|
|
if (less(buf_seqno(skb_peek_tail(list)), seq_no)) {
|
|
|
|
__skb_queue_tail(list, skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-10-25 14:44:35 +00:00
|
|
|
/* Locate insertion point in queue, then insert; discard if duplicate */
|
2014-11-26 03:41:53 +00:00
|
|
|
skb_queue_walk(list, skb1) {
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 curr_seqno = buf_seqno(skb1);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2011-10-25 14:44:35 +00:00
|
|
|
if (seq_no == curr_seqno) {
|
2014-11-26 03:41:53 +00:00
|
|
|
kfree_skb(skb);
|
2011-10-25 14:44:35 +00:00
|
|
|
return 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2011-10-25 14:44:35 +00:00
|
|
|
|
|
|
|
if (less(seq_no, curr_seqno))
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
2011-10-25 14:44:35 +00:00
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2014-11-26 03:41:53 +00:00
|
|
|
__skb_queue_before(list, skb1, skb);
|
2011-10-25 14:44:35 +00:00
|
|
|
return 1;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2011-10-25 14:44:35 +00:00
|
|
|
/*
|
2006-01-02 18:04:38 +00:00
|
|
|
* link_handle_out_of_seq_msg - handle arrival of out-of-sequence packet
|
|
|
|
*/
|
2015-02-05 13:36:36 +00:00
|
|
|
static void link_handle_out_of_seq_msg(struct tipc_link *l_ptr,
|
2006-01-02 18:04:38 +00:00
|
|
|
struct sk_buff *buf)
|
|
|
|
{
|
2011-10-24 20:03:12 +00:00
|
|
|
u32 seq_no = buf_seqno(buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
if (likely(msg_user(buf_msg(buf)) == LINK_PROTOCOL)) {
|
2015-02-05 13:36:36 +00:00
|
|
|
tipc_link_proto_rcv(l_ptr, buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-05-14 14:46:16 +00:00
|
|
|
/* Record OOS packet arrival */
|
|
|
|
l_ptr->silent_intv_cnt = 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2007-02-09 14:25:21 +00:00
|
|
|
/*
|
2006-01-02 18:04:38 +00:00
|
|
|
* Discard packet if a duplicate; otherwise add it to deferred queue
|
|
|
|
* and notify peer of gap as per protocol specification
|
|
|
|
*/
|
2015-05-14 14:46:15 +00:00
|
|
|
if (less(seq_no, l_ptr->rcv_nxt)) {
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.duplicates++;
|
2011-11-04 17:24:29 +00:00
|
|
|
kfree_skb(buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
if (tipc_link_defer_pkt(&l_ptr->deferdq, buf)) {
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.deferred_recv++;
|
2015-03-13 20:08:10 +00:00
|
|
|
if ((skb_queue_len(&l_ptr->deferdq) % TIPC_MIN_LINK_WIN) == 1)
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 0, 0, 0, 0);
|
2014-11-26 03:41:53 +00:00
|
|
|
} else {
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.duplicates++;
|
2014-11-26 03:41:53 +00:00
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send protocol message to the other endpoint.
|
|
|
|
*/
|
2014-02-18 08:06:46 +00:00
|
|
|
void tipc_link_proto_xmit(struct tipc_link *l_ptr, u32 msg_typ, int probe_msg,
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
u32 gap, u32 tolerance, u32 priority)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2006-03-21 06:36:47 +00:00
|
|
|
struct sk_buff *buf = NULL;
|
2006-01-02 18:04:38 +00:00
|
|
|
struct tipc_msg *msg = l_ptr->pmsg;
|
2007-02-09 14:25:21 +00:00
|
|
|
u32 msg_size = sizeof(l_ptr->proto_msg);
|
2011-02-28 20:30:20 +00:00
|
|
|
int r_flag;
|
2015-05-14 14:46:14 +00:00
|
|
|
u16 last_rcv;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
/* Don't send protocol message during link failover */
|
|
|
|
if (l_ptr->flags & LINK_FAILINGOVER)
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
|
|
|
|
/* Abort non-RESET send if communication with node is prohibited */
|
2014-05-05 00:56:11 +00:00
|
|
|
if ((tipc_node_blocked(l_ptr->owner)) && (msg_typ != RESET_MSG))
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
return;
|
|
|
|
|
2011-10-25 15:20:26 +00:00
|
|
|
/* Create protocol message with "out-of-sequence" sequence number */
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_type(msg, msg_typ);
|
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 02:55:46 +00:00
|
|
|
msg_set_net_plane(msg, l_ptr->net_plane);
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-27 18:17:53 +00:00
|
|
|
msg_set_bcast_ack(msg, l_ptr->owner->bclink.last_in);
|
2015-01-09 07:27:07 +00:00
|
|
|
msg_set_last_bcast(msg, tipc_bclink_get_last_sent(l_ptr->owner->net));
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
if (msg_typ == STATE_MSG) {
|
2015-05-14 14:46:15 +00:00
|
|
|
u16 next_sent = l_ptr->snd_nxt;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2006-01-17 23:38:21 +00:00
|
|
|
if (!tipc_link_is_up(l_ptr))
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
|
|
|
msg_set_next_sent(msg, next_sent);
|
2015-03-13 20:08:10 +00:00
|
|
|
if (!skb_queue_empty(&l_ptr->deferdq)) {
|
2015-05-14 14:46:14 +00:00
|
|
|
last_rcv = buf_seqno(skb_peek(&l_ptr->deferdq));
|
2015-05-14 14:46:15 +00:00
|
|
|
gap = mod(last_rcv - l_ptr->rcv_nxt);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
msg_set_seq_gap(msg, gap);
|
|
|
|
if (gap)
|
|
|
|
l_ptr->stats.sent_nacks++;
|
|
|
|
msg_set_link_tolerance(msg, tolerance);
|
|
|
|
msg_set_linkprio(msg, priority);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
msg_set_max_pkt(msg, l_ptr->mtu);
|
2015-05-14 14:46:15 +00:00
|
|
|
msg_set_ack(msg, mod(l_ptr->rcv_nxt - 1));
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_probe(msg, probe_msg != 0);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
if (probe_msg)
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.sent_probes++;
|
|
|
|
l_ptr->stats.sent_states++;
|
|
|
|
} else { /* RESET_MSG or ACTIVATE_MSG */
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
msg_set_ack(msg, mod(l_ptr->failover_checkpt - 1));
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_seq_gap(msg, 0);
|
|
|
|
msg_set_next_sent(msg, 1);
|
2011-01-18 20:15:34 +00:00
|
|
|
msg_set_probe(msg, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_link_tolerance(msg, l_ptr->tolerance);
|
|
|
|
msg_set_linkprio(msg, l_ptr->priority);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
msg_set_max_pkt(msg, l_ptr->advertised_mtu);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2011-02-28 20:30:20 +00:00
|
|
|
r_flag = (l_ptr->owner->working_links > tipc_link_is_up(l_ptr));
|
|
|
|
msg_set_redundant_link(msg, r_flag);
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_linkprio(msg, l_ptr->priority);
|
2011-10-25 15:20:26 +00:00
|
|
|
msg_set_size(msg, msg_size);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-05-14 14:46:15 +00:00
|
|
|
msg_set_seqno(msg, mod(l_ptr->snd_nxt + (0xffff / 2)));
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2010-10-13 13:20:35 +00:00
|
|
|
buf = tipc_buf_acquire(msg_size);
|
2006-01-02 18:04:38 +00:00
|
|
|
if (!buf)
|
|
|
|
return;
|
|
|
|
|
2007-03-31 14:55:19 +00:00
|
|
|
skb_copy_to_linear_data(buf, msg, sizeof(l_ptr->proto_msg));
|
2013-06-17 14:54:48 +00:00
|
|
|
buf->priority = TC_PRIO_CONTROL;
|
2015-01-09 07:27:06 +00:00
|
|
|
tipc_bearer_send(l_ptr->owner->net, l_ptr->bearer_id, buf,
|
|
|
|
&l_ptr->media_addr);
|
2015-03-13 20:08:10 +00:00
|
|
|
l_ptr->rcv_unacked = 0;
|
2011-11-04 17:24:29 +00:00
|
|
|
kfree_skb(buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Receive protocol message :
|
2007-02-09 14:25:21 +00:00
|
|
|
* Note that network plane id propagates through the network, and may
|
|
|
|
* change at any time. The node with lowest address rules
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2015-02-05 13:36:36 +00:00
|
|
|
static void tipc_link_proto_rcv(struct tipc_link *l_ptr,
|
2015-01-09 07:27:04 +00:00
|
|
|
struct sk_buff *buf)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
u32 rec_gap = 0;
|
|
|
|
u32 msg_tol;
|
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (l_ptr->flags & LINK_FAILINGOVER)
|
2006-01-02 18:04:38 +00:00
|
|
|
goto exit;
|
|
|
|
|
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 02:55:46 +00:00
|
|
|
if (l_ptr->net_plane != msg_net_plane(msg))
|
2015-02-05 13:36:36 +00:00
|
|
|
if (link_own_addr(l_ptr) > msg_prevnode(msg))
|
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 02:55:46 +00:00
|
|
|
l_ptr->net_plane = msg_net_plane(msg);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
switch (msg_type(msg)) {
|
2007-02-09 14:25:21 +00:00
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
case RESET_MSG:
|
2008-06-05 00:29:39 +00:00
|
|
|
if (!link_working_unknown(l_ptr) &&
|
|
|
|
(l_ptr->peer_session != INVALID_SESSION)) {
|
2011-04-07 13:54:43 +00:00
|
|
|
if (less_eq(msg_session(msg), l_ptr->peer_session))
|
|
|
|
break; /* duplicate or old reset: ignore */
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
|
|
|
|
if (!msg_redundant_link(msg) && (link_working_working(l_ptr) ||
|
|
|
|
link_working_unknown(l_ptr))) {
|
|
|
|
/*
|
|
|
|
* peer has lost contact -- don't allow peer's links
|
|
|
|
* to reactivate before we recognize loss & clean up
|
|
|
|
*/
|
2014-05-08 00:54:40 +00:00
|
|
|
l_ptr->owner->action_flags |= TIPC_WAIT_OWN_LINKS_DOWN;
|
tipc: Ensure both nodes recognize loss of contact between them
Enhances TIPC to ensure that a node that loses contact with a
neighboring node does not allow contact to be re-established until
it sees that its peer has also recognized the loss of contact.
Previously, nodes that were connected by two or more links could
encounter a situation in which node A would lose contact with node B
on all of its links, purge its name table of names published by B,
and then fail to repopulate those names once contact with B was restored.
This would happen because B was able to re-establish one or more links
so quickly that it never reached a point where it had no links to A --
meaning that B never saw a loss of contact with A, and consequently
didn't re-publish its names to A.
This problem is now prevented by enhancing the cleanup done by TIPC
following a loss of contact with a neighboring node to ensure that
node A ignores all messages sent by B until it receives a LINK_PROTOCOL
message that indicates B has lost contact with A, thereby preventing
the (re)establishment of links between the nodes. The loss of contact
is recognized when a RESET or ACTIVATE message is received that has
a "redundant link exists" field of 0, indicating that B's sending link
endpoint is in a reset state and that B has no other working links.
Additionally, TIPC now suppresses the sending of (most) link protocol
messages to a neighboring node while it is cleaning up after an earlier
loss of contact with that node. This stops the peer node from prematurely
activating its link endpoint, which would prevent TIPC from later
activating its own end. TIPC still allows outgoing RESET messages to
occur during cleanup, to avoid problems if its own node recognizes
the loss of contact first and tries to notify the peer of the situation.
Finally, TIPC now recognizes an impending loss of contact with a peer node
as soon as it receives a RESET message on a working link that is the
peer's only link to the node, and ensures that the link protocol
suppression mentioned above goes into effect right away -- that is,
even before its own link endpoints have failed. This is necessary to
ensure correct operation when there are redundant links between the nodes,
since otherwise TIPC would send an ACTIVATE message upon receiving a RESET
on its first link and only begin suppressing when a RESET on its second
link was received, instead of initiating suppression with the first RESET
message as it needs to.
Note: The reworked cleanup code also eliminates a check that prevented
a link endpoint's discovery object from responding to incoming messages
while stale name table entries are being purged. This check is now
unnecessary and would have slowed down re-establishment of communication
between the nodes in some situations.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-27 15:00:51 +00:00
|
|
|
}
|
|
|
|
|
2011-10-26 14:55:16 +00:00
|
|
|
link_state_event(l_ptr, RESET_MSG);
|
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
/* fall thru' */
|
|
|
|
case ACTIVATE_MSG:
|
|
|
|
/* Update link settings according other endpoint's values */
|
|
|
|
strcpy((strrchr(l_ptr->name, ':') + 1), (char *)msg_data(msg));
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
msg_tol = msg_link_tolerance(msg);
|
|
|
|
if (msg_tol > l_ptr->tolerance)
|
2006-01-02 18:04:38 +00:00
|
|
|
link_set_supervision_props(l_ptr, msg_tol);
|
|
|
|
|
|
|
|
if (msg_linkprio(msg) > l_ptr->priority)
|
|
|
|
l_ptr->priority = msg_linkprio(msg);
|
|
|
|
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
if (l_ptr->mtu > msg_max_pkt(msg))
|
|
|
|
l_ptr->mtu = msg_max_pkt(msg);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2011-10-25 16:19:05 +00:00
|
|
|
/* Synchronize broadcast link info, if not done previously */
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-27 18:17:53 +00:00
|
|
|
if (!tipc_node_is_up(l_ptr->owner)) {
|
|
|
|
l_ptr->owner->bclink.last_sent =
|
|
|
|
l_ptr->owner->bclink.last_in =
|
|
|
|
msg_last_bcast(msg);
|
|
|
|
l_ptr->owner->bclink.oos_state = 0;
|
|
|
|
}
|
2011-10-25 16:19:05 +00:00
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->peer_session = msg_session(msg);
|
|
|
|
l_ptr->peer_bearer_id = msg_bearer_id(msg);
|
2011-10-26 14:55:16 +00:00
|
|
|
|
|
|
|
if (msg_type(msg) == ACTIVATE_MSG)
|
|
|
|
link_state_event(l_ptr, ACTIVATE_MSG);
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
case STATE_MSG:
|
|
|
|
|
2010-12-31 18:59:33 +00:00
|
|
|
msg_tol = msg_link_tolerance(msg);
|
|
|
|
if (msg_tol)
|
2006-01-02 18:04:38 +00:00
|
|
|
link_set_supervision_props(l_ptr, msg_tol);
|
2007-02-09 14:25:21 +00:00
|
|
|
|
|
|
|
if (msg_linkprio(msg) &&
|
2006-01-02 18:04:38 +00:00
|
|
|
(msg_linkprio(msg) != l_ptr->priority)) {
|
2015-01-22 16:10:31 +00:00
|
|
|
pr_debug("%s<%s>, priority change %u->%u\n",
|
|
|
|
link_rst_msg, l_ptr->name,
|
|
|
|
l_ptr->priority, msg_linkprio(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->priority = msg_linkprio(msg);
|
2006-01-17 23:38:21 +00:00
|
|
|
tipc_link_reset(l_ptr); /* Enforce change to take effect */
|
2006-01-02 18:04:38 +00:00
|
|
|
break;
|
|
|
|
}
|
tipc: don't record link RESET or ACTIVATE messages as traffic
In the current code, all incoming LINK_PROTOCOL messages, irrespective
of type, nudge the "last message received" checkpoint, informing the
link state machine that a message was received from the peer since last
supervision timeout event. This inhibits the link from starting probing
the peer unnecessarily.
However, not only STATE messages are recorded as legitimate incoming
traffic this way, but even RESET and ACTIVATE messages, which in
reality are there to inform the link that the peer endpoint has been
reset. At the same time, some RESET messages may be dropped instead
of causing a link reset. This happens when the link endpoint thinks
it is fully up and working, and the session number of the RESET is
lower than or equal to the current link session. In such cases the
RESET is perceived as a delayed remnant from an earlier session, or
the current one, and dropped.
Now, if a TIPC module is removed and then immediately reinserted, e.g.
when using a script, RESET messages may arrive at the peer link endpoint
before this one has had time to discover the failure. The RESET may be
dropped because of the session number, but only after it has been
recorded as a legitimate traffic event. Hence, the receiving link will
not start probing, and not discover that the peer endpoint is down, at
the same time ignoring the periodic RESET messages coming from that
endpoint. We have ended up in a stale state where a failed link cannot
be re-established.
In this commit, we remedy this by nudging the checkpoint only for
received STATE messages, not for RESET or ACTIVATE messages.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 09:39:10 +00:00
|
|
|
|
|
|
|
/* Record reception; force mismatch at next timeout: */
|
2015-05-14 14:46:16 +00:00
|
|
|
l_ptr->silent_intv_cnt = 0;
|
tipc: don't record link RESET or ACTIVATE messages as traffic
In the current code, all incoming LINK_PROTOCOL messages, irrespective
of type, nudge the "last message received" checkpoint, informing the
link state machine that a message was received from the peer since last
supervision timeout event. This inhibits the link from starting probing
the peer unnecessarily.
However, not only STATE messages are recorded as legitimate incoming
traffic this way, but even RESET and ACTIVATE messages, which in
reality are there to inform the link that the peer endpoint has been
reset. At the same time, some RESET messages may be dropped instead
of causing a link reset. This happens when the link endpoint thinks
it is fully up and working, and the session number of the RESET is
lower than or equal to the current link session. In such cases the
RESET is perceived as a delayed remnant from an earlier session, or
the current one, and dropped.
Now, if a TIPC module is removed and then immediately reinserted, e.g.
when using a script, RESET messages may arrive at the peer link endpoint
before this one has had time to discover the failure. The RESET may be
dropped because of the session number, but only after it has been
recorded as a legitimate traffic event. Hence, the receiving link will
not start probing, and not discover that the peer endpoint is down, at
the same time ignoring the periodic RESET messages coming from that
endpoint. We have ended up in a stale state where a failed link cannot
be re-established.
In this commit, we remedy this by nudging the checkpoint only for
received STATE messages, not for RESET or ACTIVATE messages.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-14 09:39:10 +00:00
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
link_state_event(l_ptr, TRAFFIC_MSG_EVT);
|
|
|
|
l_ptr->stats.recv_states++;
|
|
|
|
if (link_reset_unknown(l_ptr))
|
|
|
|
break;
|
|
|
|
|
2015-05-14 14:46:15 +00:00
|
|
|
if (less_eq(l_ptr->rcv_nxt, msg_next_sent(msg)))
|
|
|
|
rec_gap = mod(msg_next_sent(msg) - l_ptr->rcv_nxt);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
if (msg_probe(msg))
|
2006-01-02 18:04:38 +00:00
|
|
|
l_ptr->stats.recv_probes++;
|
|
|
|
|
|
|
|
/* Protocol message before retransmits, reduce loss risk */
|
2012-11-16 05:51:30 +00:00
|
|
|
if (l_ptr->owner->bclink.recv_permitted)
|
2015-02-05 13:36:36 +00:00
|
|
|
tipc_bclink_update_link_state(l_ptr->owner,
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-27 18:17:53 +00:00
|
|
|
msg_last_bcast(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
if (rec_gap || (msg_probe(msg))) {
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(l_ptr, STATE_MSG, 0,
|
|
|
|
rec_gap, 0, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
if (msg_seq_gap(msg)) {
|
|
|
|
l_ptr->stats.recv_nacks++;
|
2015-03-13 20:08:10 +00:00
|
|
|
tipc_link_retransmit(l_ptr, skb_peek(&l_ptr->transmq),
|
2006-01-17 23:38:21 +00:00
|
|
|
msg_seq_gap(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
exit:
|
2011-11-04 17:24:29 +00:00
|
|
|
kfree_skb(buf);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-07 22:02:41 +00:00
|
|
|
/* tipc_link_tunnel_xmit(): Tunnel one packet via a link belonging to
|
|
|
|
* a different bearer. Owner node is locked.
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2014-01-07 22:02:41 +00:00
|
|
|
static void tipc_link_tunnel_xmit(struct tipc_link *l_ptr,
|
|
|
|
struct tipc_msg *tunnel_hdr,
|
|
|
|
struct tipc_msg *msg,
|
|
|
|
u32 selector)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2011-12-30 01:58:42 +00:00
|
|
|
struct tipc_link *tunnel;
|
2014-11-26 03:41:55 +00:00
|
|
|
struct sk_buff *skb;
|
2006-01-02 18:04:38 +00:00
|
|
|
u32 length = msg_size(msg);
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
tunnel = node_active_link(l_ptr->owner, selector & 1);
|
2006-06-26 06:52:50 +00:00
|
|
|
if (!tipc_link_is_up(tunnel)) {
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("%stunnel link no longer available\n", link_co_err);
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
2006-06-26 06:52:50 +00:00
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_size(tunnel_hdr, length + INT_H_SIZE);
|
2014-11-26 03:41:55 +00:00
|
|
|
skb = tipc_buf_acquire(length + INT_H_SIZE);
|
|
|
|
if (!skb) {
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("%sunable to send tunnel msg\n", link_co_err);
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
2006-06-26 06:52:50 +00:00
|
|
|
}
|
2014-11-26 03:41:55 +00:00
|
|
|
skb_copy_to_linear_data(skb, tunnel_hdr, INT_H_SIZE);
|
|
|
|
skb_copy_to_linear_data_offset(skb, INT_H_SIZE, msg, length);
|
|
|
|
__tipc_link_xmit_skb(tunnel, skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-07 22:02:41 +00:00
|
|
|
/* tipc_link_failover_send_queue(): A link has gone down, but a second
|
|
|
|
* link is still active. We can do failover. Tunnel the failing link's
|
|
|
|
* whole send queue via the remaining link. This way, we don't lose
|
|
|
|
* any packets, and sequence order is preserved for subsequent traffic
|
|
|
|
* sent over the remaining link. Owner node is locked.
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2014-01-07 22:02:41 +00:00
|
|
|
void tipc_link_failover_send_queue(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-03-13 20:08:10 +00:00
|
|
|
int msgcount;
|
2015-07-16 20:54:19 +00:00
|
|
|
struct tipc_link *tunnel = node_active_link(l_ptr->owner, 0);
|
2006-01-02 18:04:38 +00:00
|
|
|
struct tipc_msg tunnel_hdr;
|
2014-11-26 03:41:52 +00:00
|
|
|
struct sk_buff *skb;
|
2006-06-26 06:52:50 +00:00
|
|
|
int split_bundles;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
if (!tunnel)
|
|
|
|
return;
|
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
tipc_msg_init(link_own_addr(l_ptr), &tunnel_hdr, TUNNEL_PROTOCOL,
|
|
|
|
FAILOVER_MSG, INT_H_SIZE, l_ptr->addr);
|
2015-05-14 14:46:18 +00:00
|
|
|
|
|
|
|
skb_queue_walk(&l_ptr->backlogq, skb) {
|
|
|
|
msg_set_seqno(buf_msg(skb), l_ptr->snd_nxt);
|
|
|
|
l_ptr->snd_nxt = mod(l_ptr->snd_nxt + 1);
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_queue_splice_tail_init(&l_ptr->backlogq, &l_ptr->transmq);
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
tipc_link_purge_backlog(l_ptr);
|
2015-03-13 20:08:10 +00:00
|
|
|
msgcount = skb_queue_len(&l_ptr->transmq);
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_bearer_id(&tunnel_hdr, l_ptr->peer_bearer_id);
|
|
|
|
msg_set_msgcnt(&tunnel_hdr, msgcount);
|
2006-06-26 06:51:37 +00:00
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
if (skb_queue_empty(&l_ptr->transmq)) {
|
2014-11-26 03:41:52 +00:00
|
|
|
skb = tipc_buf_acquire(INT_H_SIZE);
|
|
|
|
if (skb) {
|
|
|
|
skb_copy_to_linear_data(skb, &tunnel_hdr, INT_H_SIZE);
|
2006-01-02 18:04:38 +00:00
|
|
|
msg_set_size(&tunnel_hdr, INT_H_SIZE);
|
2014-11-26 03:41:55 +00:00
|
|
|
__tipc_link_xmit_skb(tunnel, skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
} else {
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("%sunable to send changeover msg\n",
|
|
|
|
link_co_err);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
2006-06-26 06:51:37 +00:00
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
split_bundles = (node_active_link(l_ptr->owner, 0) !=
|
|
|
|
node_active_link(l_ptr->owner, 0));
|
2006-06-26 06:52:50 +00:00
|
|
|
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_queue_walk(&l_ptr->transmq, skb) {
|
2014-11-26 03:41:52 +00:00
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
|
|
|
if ((msg_user(msg) == MSG_BUNDLER) && split_bundles) {
|
|
|
|
struct tipc_msg *m = msg_get_wrapped(msg);
|
2010-12-31 18:59:32 +00:00
|
|
|
unchar *pos = (unchar *)m;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2007-08-03 02:28:06 +00:00
|
|
|
msgcount = msg_msgcnt(msg);
|
2006-01-02 18:04:38 +00:00
|
|
|
while (msgcount--) {
|
2010-12-31 18:59:32 +00:00
|
|
|
msg_set_seqno(m, msg_seqno(msg));
|
2014-01-07 22:02:41 +00:00
|
|
|
tipc_link_tunnel_xmit(l_ptr, &tunnel_hdr, m,
|
|
|
|
msg_link_selector(m));
|
2006-01-02 18:04:38 +00:00
|
|
|
pos += align(msg_size(m));
|
|
|
|
m = (struct tipc_msg *)pos;
|
|
|
|
}
|
|
|
|
} else {
|
2014-01-07 22:02:41 +00:00
|
|
|
tipc_link_tunnel_xmit(l_ptr, &tunnel_hdr, msg,
|
|
|
|
msg_link_selector(msg));
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-18 08:06:46 +00:00
|
|
|
/* tipc_link_dup_queue_xmit(): A second link has become active. Tunnel a
|
2014-01-07 22:02:41 +00:00
|
|
|
* duplicate of the first link's send queue via the new link. This way, we
|
|
|
|
* are guaranteed that currently queued packets from a socket are delivered
|
|
|
|
* before future traffic from the same socket, even if this is using the
|
|
|
|
* new link. The last arriving copy of each duplicate packet is dropped at
|
|
|
|
* the receiving end by the regular protocol check, so packet cardinality
|
|
|
|
* and sequence order is preserved per sender/receiver socket pair.
|
|
|
|
* Owner node is locked.
|
|
|
|
*/
|
2015-03-13 20:08:10 +00:00
|
|
|
void tipc_link_dup_queue_xmit(struct tipc_link *link,
|
|
|
|
struct tipc_link *tnl)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2014-11-26 03:41:52 +00:00
|
|
|
struct sk_buff *skb;
|
2015-03-13 20:08:10 +00:00
|
|
|
struct tipc_msg tnl_hdr;
|
|
|
|
struct sk_buff_head *queue = &link->transmq;
|
|
|
|
int mcnt;
|
2015-05-14 14:46:18 +00:00
|
|
|
u16 seqno;
|
2015-03-13 20:08:10 +00:00
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
tipc_msg_init(link_own_addr(link), &tnl_hdr, TUNNEL_PROTOCOL,
|
|
|
|
SYNCH_MSG, INT_H_SIZE, link->addr);
|
2015-03-13 20:08:10 +00:00
|
|
|
mcnt = skb_queue_len(&link->transmq) + skb_queue_len(&link->backlogq);
|
|
|
|
msg_set_msgcnt(&tnl_hdr, mcnt);
|
|
|
|
msg_set_bearer_id(&tnl_hdr, link->peer_bearer_id);
|
|
|
|
|
|
|
|
tunnel_queue:
|
|
|
|
skb_queue_walk(queue, skb) {
|
2014-11-26 03:41:52 +00:00
|
|
|
struct sk_buff *outskb;
|
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
2015-03-13 20:08:10 +00:00
|
|
|
u32 len = msg_size(msg);
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-05-14 14:46:15 +00:00
|
|
|
msg_set_ack(msg, mod(link->rcv_nxt - 1));
|
2015-03-13 20:08:10 +00:00
|
|
|
msg_set_bcast_ack(msg, link->owner->bclink.last_in);
|
|
|
|
msg_set_size(&tnl_hdr, len + INT_H_SIZE);
|
|
|
|
outskb = tipc_buf_acquire(len + INT_H_SIZE);
|
2014-11-26 03:41:52 +00:00
|
|
|
if (outskb == NULL) {
|
2012-06-29 04:16:37 +00:00
|
|
|
pr_warn("%sunable to send duplicate msg\n",
|
|
|
|
link_co_err);
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
skb_copy_to_linear_data(outskb, &tnl_hdr, INT_H_SIZE);
|
|
|
|
skb_copy_to_linear_data_offset(outskb, INT_H_SIZE,
|
|
|
|
skb->data, len);
|
|
|
|
__tipc_link_xmit_skb(tnl, outskb);
|
|
|
|
if (!tipc_link_is_up(link))
|
2006-01-02 18:04:38 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
if (queue == &link->backlogq)
|
|
|
|
return;
|
2015-05-14 14:46:18 +00:00
|
|
|
seqno = link->snd_nxt;
|
|
|
|
skb_queue_walk(&link->backlogq, skb) {
|
|
|
|
msg_set_seqno(buf_msg(skb), seqno);
|
|
|
|
seqno = mod(seqno + 1);
|
|
|
|
}
|
2015-03-13 20:08:10 +00:00
|
|
|
queue = &link->backlogq;
|
|
|
|
goto tunnel_queue;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
/* tipc_link_failover_rcv(): Receive a tunnelled FAILOVER_MSG packet
|
tipc: change reception of tunnelled failover packets
When a link is reset, and there is a redundant link available, all
sender sockets will steer their subsequent traffic through the
remaining link. In order to guarantee preserved packet order and
cardinality during the transition, we tunnel the failing link's send
queue through the remaining link before we allow any sockets to use it.
In this commit, we change the algorithm for receiving failover
("ORIGINAL_MSG") packets in tipc_link_tunnel_rcv(), at the same time
delegating it to a new subfuncton, tipc_link_failover_rcv(). Instead
of directly returning an extracted inner packet to the packet reception
loop in tipc_rcv(), we first check if it is a message fragment, in which
case we append it to the reset link's fragment chain. If the fragment
chain is complete, we return the whole chain instead of the individual
buffer, eliminating any need for the tipc_rcv() loop to do reassembly of
tunneled packets.
This change makes it possible to further simplify tipc_link_tunnel_rcv(),
as well as the calling tipc_rcv() loop. We will do that in later
commits. It also makes it possible to identify a single spot in the code
where we can tell that a failover procedure is finished, something that
is useful when we are deleting links after a failover. This will also
be done in a later commit.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:11 +00:00
|
|
|
* Owner node is locked.
|
|
|
|
*/
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
static bool tipc_link_failover_rcv(struct tipc_link *link,
|
2015-04-02 13:33:00 +00:00
|
|
|
struct sk_buff **skb)
|
tipc: change reception of tunnelled failover packets
When a link is reset, and there is a redundant link available, all
sender sockets will steer their subsequent traffic through the
remaining link. In order to guarantee preserved packet order and
cardinality during the transition, we tunnel the failing link's send
queue through the remaining link before we allow any sockets to use it.
In this commit, we change the algorithm for receiving failover
("ORIGINAL_MSG") packets in tipc_link_tunnel_rcv(), at the same time
delegating it to a new subfuncton, tipc_link_failover_rcv(). Instead
of directly returning an extracted inner packet to the packet reception
loop in tipc_rcv(), we first check if it is a message fragment, in which
case we append it to the reset link's fragment chain. If the fragment
chain is complete, we return the whole chain instead of the individual
buffer, eliminating any need for the tipc_rcv() loop to do reassembly of
tunneled packets.
This change makes it possible to further simplify tipc_link_tunnel_rcv(),
as well as the calling tipc_rcv() loop. We will do that in later
commits. It also makes it possible to identify a single spot in the code
where we can tell that a failover procedure is finished, something that
is useful when we are deleting links after a failover. This will also
be done in a later commit.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:11 +00:00
|
|
|
{
|
2015-04-02 13:33:00 +00:00
|
|
|
struct tipc_msg *msg = buf_msg(*skb);
|
|
|
|
struct sk_buff *iskb = NULL;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
struct tipc_link *pl = NULL;
|
2015-04-02 13:33:00 +00:00
|
|
|
int bearer_id = msg_bearer_id(msg);
|
2015-03-13 20:08:08 +00:00
|
|
|
int pos = 0;
|
tipc: change reception of tunnelled failover packets
When a link is reset, and there is a redundant link available, all
sender sockets will steer their subsequent traffic through the
remaining link. In order to guarantee preserved packet order and
cardinality during the transition, we tunnel the failing link's send
queue through the remaining link before we allow any sockets to use it.
In this commit, we change the algorithm for receiving failover
("ORIGINAL_MSG") packets in tipc_link_tunnel_rcv(), at the same time
delegating it to a new subfuncton, tipc_link_failover_rcv(). Instead
of directly returning an extracted inner packet to the packet reception
loop in tipc_rcv(), we first check if it is a message fragment, in which
case we append it to the reset link's fragment chain. If the fragment
chain is complete, we return the whole chain instead of the individual
buffer, eliminating any need for the tipc_rcv() loop to do reassembly of
tunneled packets.
This change makes it possible to further simplify tipc_link_tunnel_rcv(),
as well as the calling tipc_rcv() loop. We will do that in later
commits. It also makes it possible to identify a single spot in the code
where we can tell that a failover procedure is finished, something that
is useful when we are deleting links after a failover. This will also
be done in a later commit.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:11 +00:00
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (msg_type(msg) != FAILOVER_MSG) {
|
2015-04-02 13:33:00 +00:00
|
|
|
pr_warn("%sunknown tunnel pkt received\n", link_co_err);
|
|
|
|
goto exit;
|
tipc: change reception of tunnelled failover packets
When a link is reset, and there is a redundant link available, all
sender sockets will steer their subsequent traffic through the
remaining link. In order to guarantee preserved packet order and
cardinality during the transition, we tunnel the failing link's send
queue through the remaining link before we allow any sockets to use it.
In this commit, we change the algorithm for receiving failover
("ORIGINAL_MSG") packets in tipc_link_tunnel_rcv(), at the same time
delegating it to a new subfuncton, tipc_link_failover_rcv(). Instead
of directly returning an extracted inner packet to the packet reception
loop in tipc_rcv(), we first check if it is a message fragment, in which
case we append it to the reset link's fragment chain. If the fragment
chain is complete, we return the whole chain instead of the individual
buffer, eliminating any need for the tipc_rcv() loop to do reassembly of
tunneled packets.
This change makes it possible to further simplify tipc_link_tunnel_rcv(),
as well as the calling tipc_rcv() loop. We will do that in later
commits. It also makes it possible to identify a single spot in the code
where we can tell that a failover procedure is finished, something that
is useful when we are deleting links after a failover. This will also
be done in a later commit.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:11 +00:00
|
|
|
}
|
2015-04-02 13:33:00 +00:00
|
|
|
if (bearer_id >= MAX_BEARERS)
|
|
|
|
goto exit;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
|
|
|
|
if (bearer_id == link->bearer_id)
|
2015-04-02 13:33:00 +00:00
|
|
|
goto exit;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
pl = link->owner->links[bearer_id].link;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (pl && tipc_link_is_up(pl))
|
|
|
|
tipc_link_reset(pl);
|
|
|
|
|
|
|
|
if (link->failover_pkts == FIRST_FAILOVER)
|
|
|
|
link->failover_pkts = msg_msgcnt(msg);
|
2014-02-13 22:29:13 +00:00
|
|
|
|
2015-04-02 13:33:00 +00:00
|
|
|
/* Should we expect an inner packet? */
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (!link->failover_pkts)
|
2013-05-06 08:28:41 +00:00
|
|
|
goto exit;
|
tipc: change reception of tunnelled duplicate packets
When a second link to a destination comes up, some sender sockets will
steer their subsequent traffic through the new link. In order to
guarantee preserved packet order and cardinality for those sockets, we
tunnel a duplicate of the old link's send queue through the new link
before we open it for regular traffic. The last arriving packet copy,
on whichever link, will be dropped at the receiving end based on the
original sequence number, to ensure that only one copy is delivered to
the end receiver.
In this commit, we change the algorithm for receiving DUPLICATE_MSG
packets, at the same time delegating it to a new subfunction,
tipc_link_dup_rcv(). Instead of returning an extracted inner packet to
the packet reception loop in tipc_rcv(), we just add it to the receiving
(new) link's deferred packet queue. The packet will then be processed by
that link when it receives its first non-tunneled packet, i.e., at
latest when the changeover procedure is finished.
Because tipc_link_tunnel_rcv()/tipc_link_dup_rcv() now is consuming all
packets of type DUPLICATE_MSG, the calling tipc_rcv() function can omit
testing for this. This in turn means that the current conditional jump
to the label 'protocol_check' becomes redundant, and we can remove that
label.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 22:29:10 +00:00
|
|
|
|
2015-04-02 13:33:00 +00:00
|
|
|
if (!tipc_msg_extract(*skb, &iskb, &pos)) {
|
|
|
|
pr_warn("%sno inner failover pkt\n", link_co_err);
|
|
|
|
*skb = NULL;
|
2006-01-02 18:04:38 +00:00
|
|
|
goto exit;
|
2015-04-02 13:33:00 +00:00
|
|
|
}
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
link->failover_pkts--;
|
2015-04-02 13:33:00 +00:00
|
|
|
*skb = NULL;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
/* Was this packet already delivered? */
|
|
|
|
if (less(buf_seqno(iskb), link->failover_checkpt)) {
|
2015-04-02 13:33:00 +00:00
|
|
|
kfree_skb(iskb);
|
|
|
|
iskb = NULL;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
if (msg_user(buf_msg(iskb)) == MSG_FRAGMENTER) {
|
|
|
|
link->stats.recv_fragments++;
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
tipc_buf_append(&link->failover_skb, &iskb);
|
2015-04-02 13:33:00 +00:00
|
|
|
}
|
2006-01-02 18:04:38 +00:00
|
|
|
exit:
|
tipc: eliminate delayed link deletion at link failover
When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.
In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.
We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.
Reviewed-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>
2015-04-02 13:33:01 +00:00
|
|
|
if (!link->failover_pkts && pl)
|
|
|
|
pl->flags &= ~LINK_FAILINGOVER;
|
2015-04-02 13:33:00 +00:00
|
|
|
kfree_skb(*skb);
|
|
|
|
*skb = iskb;
|
|
|
|
return *skb;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2015-01-09 07:27:00 +00:00
|
|
|
static void link_set_supervision_props(struct tipc_link *l_ptr, u32 tol)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:00 +00:00
|
|
|
unsigned long intv = ((tol / 4) > 500) ? 500 : tol / 4;
|
|
|
|
|
|
|
|
if ((tol < TIPC_MIN_LINK_TOL) || (tol > TIPC_MAX_LINK_TOL))
|
2011-01-18 18:24:55 +00:00
|
|
|
return;
|
|
|
|
|
2015-01-09 07:27:00 +00:00
|
|
|
l_ptr->tolerance = tol;
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->keepalive_intv = msecs_to_jiffies(intv);
|
|
|
|
l_ptr->abort_limit = tol / (jiffies_to_msecs(l_ptr->keepalive_intv));
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
tipc: clean up handling of message priorities
Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.
There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.
This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.
In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.
This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-13 20:08:11 +00:00
|
|
|
void tipc_link_set_queue_limits(struct tipc_link *l, u32 win)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
int max_bulk = TIPC_MAX_PUBLICATIONS / (l->mtu / ITEM_SIZE);
|
tipc: clean up handling of message priorities
Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.
There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.
This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.
In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.
This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-13 20:08:11 +00:00
|
|
|
|
|
|
|
l->window = win;
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
l->backlog[TIPC_LOW_IMPORTANCE].limit = win / 2;
|
|
|
|
l->backlog[TIPC_MEDIUM_IMPORTANCE].limit = win;
|
|
|
|
l->backlog[TIPC_HIGH_IMPORTANCE].limit = win / 2 * 3;
|
|
|
|
l->backlog[TIPC_CRITICAL_IMPORTANCE].limit = win * 2;
|
|
|
|
l->backlog[TIPC_SYSTEM_IMPORTANCE].limit = max_bulk;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2014-02-13 22:29:18 +00:00
|
|
|
/* tipc_link_find_owner - locate owner node of link by link's name
|
2015-01-09 07:27:05 +00:00
|
|
|
* @net: the applicable net namespace
|
2014-02-13 22:29:18 +00:00
|
|
|
* @name: pointer to link name string
|
|
|
|
* @bearer_id: pointer to index in 'node->links' array where the link was found.
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
2014-02-13 22:29:18 +00:00
|
|
|
* Returns pointer to node owning the link, or 0 if no matching link is found.
|
2006-01-02 18:04:38 +00:00
|
|
|
*/
|
2015-01-09 07:27:05 +00:00
|
|
|
static struct tipc_node *tipc_link_find_owner(struct net *net,
|
|
|
|
const char *link_name,
|
2014-02-13 22:29:18 +00:00
|
|
|
unsigned int *bearer_id)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:05 +00:00
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
2011-12-30 01:58:42 +00:00
|
|
|
struct tipc_link *l_ptr;
|
2013-10-18 05:23:21 +00:00
|
|
|
struct tipc_node *n_ptr;
|
2014-12-25 11:05:50 +00:00
|
|
|
struct tipc_node *found_node = NULL;
|
2013-10-18 05:23:21 +00:00
|
|
|
int i;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2014-02-13 22:29:18 +00:00
|
|
|
*bearer_id = 0;
|
2014-03-27 04:54:37 +00:00
|
|
|
rcu_read_lock();
|
2015-01-09 07:27:05 +00:00
|
|
|
list_for_each_entry_rcu(n_ptr, &tn->node_list, list) {
|
2014-02-14 21:40:44 +00:00
|
|
|
tipc_node_lock(n_ptr);
|
2013-10-18 05:23:21 +00:00
|
|
|
for (i = 0; i < MAX_BEARERS; i++) {
|
2015-07-16 20:54:19 +00:00
|
|
|
l_ptr = n_ptr->links[i].link;
|
2014-02-13 22:29:18 +00:00
|
|
|
if (l_ptr && !strcmp(l_ptr->name, link_name)) {
|
|
|
|
*bearer_id = i;
|
|
|
|
found_node = n_ptr;
|
|
|
|
break;
|
|
|
|
}
|
2013-10-18 05:23:21 +00:00
|
|
|
}
|
2014-02-14 21:40:44 +00:00
|
|
|
tipc_node_unlock(n_ptr);
|
2014-02-13 22:29:18 +00:00
|
|
|
if (found_node)
|
|
|
|
break;
|
2013-10-18 05:23:21 +00:00
|
|
|
}
|
2014-03-27 04:54:37 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
2014-02-13 22:29:18 +00:00
|
|
|
return found_node;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* link_reset_statistics - reset link statistics
|
|
|
|
* @l_ptr: pointer to link
|
|
|
|
*/
|
2011-12-30 01:58:42 +00:00
|
|
|
static void link_reset_statistics(struct tipc_link *l_ptr)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
|
|
|
memset(&l_ptr->stats, 0, sizeof(l_ptr->stats));
|
2015-05-14 14:46:15 +00:00
|
|
|
l_ptr->stats.sent_info = l_ptr->snd_nxt;
|
|
|
|
l_ptr->stats.recv_info = l_ptr->rcv_nxt;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 01:58:42 +00:00
|
|
|
static void link_print(struct tipc_link *l_ptr, const char *str)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:06 +00:00
|
|
|
struct tipc_net *tn = net_generic(l_ptr->owner->net, tipc_net_id);
|
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 02:55:46 +00:00
|
|
|
struct tipc_bearer *b_ptr;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2015-01-09 07:27:06 +00:00
|
|
|
b_ptr = rcu_dereference_rtnl(tn->bearer_list[l_ptr->bearer_id]);
|
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 02:55:46 +00:00
|
|
|
if (b_ptr)
|
|
|
|
pr_info("%s Link %x<%s>:", str, l_ptr->addr, b_ptr->name);
|
|
|
|
rcu_read_unlock();
|
2010-12-31 18:59:27 +00:00
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
if (link_working_unknown(l_ptr))
|
2012-07-11 23:27:56 +00:00
|
|
|
pr_cont(":WU\n");
|
2010-12-31 18:59:27 +00:00
|
|
|
else if (link_reset_reset(l_ptr))
|
2012-07-11 23:27:56 +00:00
|
|
|
pr_cont(":RR\n");
|
2010-12-31 18:59:27 +00:00
|
|
|
else if (link_reset_unknown(l_ptr))
|
2012-07-11 23:27:56 +00:00
|
|
|
pr_cont(":RU\n");
|
2010-12-31 18:59:27 +00:00
|
|
|
else if (link_working_working(l_ptr))
|
2012-07-11 23:27:56 +00:00
|
|
|
pr_cont(":WW\n");
|
|
|
|
else
|
|
|
|
pr_cont("\n");
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2014-11-20 09:29:07 +00:00
|
|
|
|
|
|
|
/* Parse and validate nested (link) properties valid for media, bearer and link
|
|
|
|
*/
|
|
|
|
int tipc_nl_parse_link_prop(struct nlattr *prop, struct nlattr *props[])
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = nla_parse_nested(props, TIPC_NLA_PROP_MAX, prop,
|
|
|
|
tipc_nl_prop_policy);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (props[TIPC_NLA_PROP_PRIO]) {
|
|
|
|
u32 prio;
|
|
|
|
|
|
|
|
prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
|
|
|
|
if (prio > TIPC_MAX_LINK_PRI)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (props[TIPC_NLA_PROP_TOL]) {
|
|
|
|
u32 tol;
|
|
|
|
|
|
|
|
tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
|
|
|
|
if ((tol < TIPC_MIN_LINK_TOL) || (tol > TIPC_MAX_LINK_TOL))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (props[TIPC_NLA_PROP_WIN]) {
|
|
|
|
u32 win;
|
|
|
|
|
|
|
|
win = nla_get_u32(props[TIPC_NLA_PROP_WIN]);
|
|
|
|
if ((win < TIPC_MIN_LINK_WIN) || (win > TIPC_MAX_LINK_WIN))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2014-11-20 09:29:13 +00:00
|
|
|
int tipc_nl_link_set(struct sk_buff *skb, struct genl_info *info)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int res = 0;
|
|
|
|
int bearer_id;
|
|
|
|
char *name;
|
|
|
|
struct tipc_link *link;
|
|
|
|
struct tipc_node *node;
|
|
|
|
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
|
2015-02-09 08:50:08 +00:00
|
|
|
struct net *net = sock_net(skb->sk);
|
2014-11-20 09:29:13 +00:00
|
|
|
|
|
|
|
if (!info->attrs[TIPC_NLA_LINK])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
err = nla_parse_nested(attrs, TIPC_NLA_LINK_MAX,
|
|
|
|
info->attrs[TIPC_NLA_LINK],
|
|
|
|
tipc_nl_link_policy);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (!attrs[TIPC_NLA_LINK_NAME])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
|
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
if (strcmp(name, tipc_bclink_name) == 0)
|
|
|
|
return tipc_nl_bc_link_set(net, attrs);
|
|
|
|
|
2015-01-09 07:27:05 +00:00
|
|
|
node = tipc_link_find_owner(net, name, &bearer_id);
|
2014-11-20 09:29:13 +00:00
|
|
|
if (!node)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
tipc_node_lock(node);
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
link = node->links[bearer_id].link;
|
2014-11-20 09:29:13 +00:00
|
|
|
if (!link) {
|
|
|
|
res = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (attrs[TIPC_NLA_LINK_PROP]) {
|
|
|
|
struct nlattr *props[TIPC_NLA_PROP_MAX + 1];
|
|
|
|
|
|
|
|
err = tipc_nl_parse_link_prop(attrs[TIPC_NLA_LINK_PROP],
|
|
|
|
props);
|
|
|
|
if (err) {
|
|
|
|
res = err;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (props[TIPC_NLA_PROP_TOL]) {
|
|
|
|
u32 tol;
|
|
|
|
|
|
|
|
tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
|
|
|
|
link_set_supervision_props(link, tol);
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
|
2014-11-20 09:29:13 +00:00
|
|
|
}
|
|
|
|
if (props[TIPC_NLA_PROP_PRIO]) {
|
|
|
|
u32 prio;
|
|
|
|
|
|
|
|
prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
|
|
|
|
link->priority = prio;
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, prio);
|
2014-11-20 09:29:13 +00:00
|
|
|
}
|
|
|
|
if (props[TIPC_NLA_PROP_WIN]) {
|
|
|
|
u32 win;
|
|
|
|
|
|
|
|
win = nla_get_u32(props[TIPC_NLA_PROP_WIN]);
|
|
|
|
tipc_link_set_queue_limits(link, win);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
tipc_node_unlock(node);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
2014-11-24 10:10:29 +00:00
|
|
|
|
|
|
|
static int __tipc_nl_add_stats(struct sk_buff *skb, struct tipc_stats *s)
|
2014-11-20 09:29:12 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct nlattr *stats;
|
|
|
|
|
|
|
|
struct nla_map {
|
|
|
|
u32 key;
|
|
|
|
u32 val;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nla_map map[] = {
|
|
|
|
{TIPC_NLA_STATS_RX_INFO, s->recv_info},
|
|
|
|
{TIPC_NLA_STATS_RX_FRAGMENTS, s->recv_fragments},
|
|
|
|
{TIPC_NLA_STATS_RX_FRAGMENTED, s->recv_fragmented},
|
|
|
|
{TIPC_NLA_STATS_RX_BUNDLES, s->recv_bundles},
|
|
|
|
{TIPC_NLA_STATS_RX_BUNDLED, s->recv_bundled},
|
|
|
|
{TIPC_NLA_STATS_TX_INFO, s->sent_info},
|
|
|
|
{TIPC_NLA_STATS_TX_FRAGMENTS, s->sent_fragments},
|
|
|
|
{TIPC_NLA_STATS_TX_FRAGMENTED, s->sent_fragmented},
|
|
|
|
{TIPC_NLA_STATS_TX_BUNDLES, s->sent_bundles},
|
|
|
|
{TIPC_NLA_STATS_TX_BUNDLED, s->sent_bundled},
|
|
|
|
{TIPC_NLA_STATS_MSG_PROF_TOT, (s->msg_length_counts) ?
|
|
|
|
s->msg_length_counts : 1},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_CNT, s->msg_length_counts},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_TOT, s->msg_lengths_total},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P0, s->msg_length_profile[0]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P1, s->msg_length_profile[1]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P2, s->msg_length_profile[2]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P3, s->msg_length_profile[3]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P4, s->msg_length_profile[4]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P5, s->msg_length_profile[5]},
|
|
|
|
{TIPC_NLA_STATS_MSG_LEN_P6, s->msg_length_profile[6]},
|
|
|
|
{TIPC_NLA_STATS_RX_STATES, s->recv_states},
|
|
|
|
{TIPC_NLA_STATS_RX_PROBES, s->recv_probes},
|
|
|
|
{TIPC_NLA_STATS_RX_NACKS, s->recv_nacks},
|
|
|
|
{TIPC_NLA_STATS_RX_DEFERRED, s->deferred_recv},
|
|
|
|
{TIPC_NLA_STATS_TX_STATES, s->sent_states},
|
|
|
|
{TIPC_NLA_STATS_TX_PROBES, s->sent_probes},
|
|
|
|
{TIPC_NLA_STATS_TX_NACKS, s->sent_nacks},
|
|
|
|
{TIPC_NLA_STATS_TX_ACKS, s->sent_acks},
|
|
|
|
{TIPC_NLA_STATS_RETRANSMITTED, s->retransmitted},
|
|
|
|
{TIPC_NLA_STATS_DUPLICATES, s->duplicates},
|
|
|
|
{TIPC_NLA_STATS_LINK_CONGS, s->link_congs},
|
|
|
|
{TIPC_NLA_STATS_MAX_QUEUE, s->max_queue_sz},
|
|
|
|
{TIPC_NLA_STATS_AVG_QUEUE, s->queue_sz_counts ?
|
|
|
|
(s->accu_queue_sz / s->queue_sz_counts) : 0}
|
|
|
|
};
|
|
|
|
|
|
|
|
stats = nla_nest_start(skb, TIPC_NLA_LINK_STATS);
|
|
|
|
if (!stats)
|
|
|
|
return -EMSGSIZE;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(map); i++)
|
|
|
|
if (nla_put_u32(skb, map[i].key, map[i].val))
|
|
|
|
goto msg_full;
|
|
|
|
|
|
|
|
nla_nest_end(skb, stats);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
msg_full:
|
|
|
|
nla_nest_cancel(skb, stats);
|
|
|
|
|
|
|
|
return -EMSGSIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Caller should hold appropriate locks to protect the link */
|
2015-01-09 07:27:10 +00:00
|
|
|
static int __tipc_nl_add_link(struct net *net, struct tipc_nl_msg *msg,
|
2015-04-28 16:33:50 +00:00
|
|
|
struct tipc_link *link, int nlflags)
|
2014-11-20 09:29:12 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
void *hdr;
|
|
|
|
struct nlattr *attrs;
|
|
|
|
struct nlattr *prop;
|
2015-01-09 07:27:10 +00:00
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-02-09 08:50:03 +00:00
|
|
|
hdr = genlmsg_put(msg->skb, msg->portid, msg->seq, &tipc_genl_family,
|
2015-04-28 16:33:50 +00:00
|
|
|
nlflags, TIPC_NL_LINK_GET);
|
2014-11-20 09:29:12 +00:00
|
|
|
if (!hdr)
|
|
|
|
return -EMSGSIZE;
|
|
|
|
|
|
|
|
attrs = nla_nest_start(msg->skb, TIPC_NLA_LINK);
|
|
|
|
if (!attrs)
|
|
|
|
goto msg_full;
|
|
|
|
|
|
|
|
if (nla_put_string(msg->skb, TIPC_NLA_LINK_NAME, link->name))
|
|
|
|
goto attr_msg_full;
|
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_LINK_DEST,
|
2015-01-09 07:27:10 +00:00
|
|
|
tipc_cluster_mask(tn->own_addr)))
|
2014-11-20 09:29:12 +00:00
|
|
|
goto attr_msg_full;
|
tipc: simplify link mtu negotiation
When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.
However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.
Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.
In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.
Reviewed-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>
2015-04-02 13:33:02 +00:00
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_LINK_MTU, link->mtu))
|
2014-11-20 09:29:12 +00:00
|
|
|
goto attr_msg_full;
|
2015-05-14 14:46:15 +00:00
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_LINK_RX, link->rcv_nxt))
|
2014-11-20 09:29:12 +00:00
|
|
|
goto attr_msg_full;
|
2015-05-14 14:46:15 +00:00
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_LINK_TX, link->snd_nxt))
|
2014-11-20 09:29:12 +00:00
|
|
|
goto attr_msg_full;
|
|
|
|
|
|
|
|
if (tipc_link_is_up(link))
|
|
|
|
if (nla_put_flag(msg->skb, TIPC_NLA_LINK_UP))
|
|
|
|
goto attr_msg_full;
|
|
|
|
if (tipc_link_is_active(link))
|
|
|
|
if (nla_put_flag(msg->skb, TIPC_NLA_LINK_ACTIVE))
|
|
|
|
goto attr_msg_full;
|
|
|
|
|
|
|
|
prop = nla_nest_start(msg->skb, TIPC_NLA_LINK_PROP);
|
|
|
|
if (!prop)
|
|
|
|
goto attr_msg_full;
|
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_PROP_PRIO, link->priority))
|
|
|
|
goto prop_msg_full;
|
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_PROP_TOL, link->tolerance))
|
|
|
|
goto prop_msg_full;
|
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_PROP_WIN,
|
tipc: introduce starvation free send algorithm
Currently, we only use a single counter; the length of the backlog
queue, to determine whether a message should be accepted to the queue
or not. Each time a message is being sent, the queue length is compared
to a threshold value for the message's importance priority. If the queue
length is beyond this threshold, the message is rejected. This algorithm
implies a risk of starvation of low importance senders during very high
load, because it may take a long time before the backlog queue has
decreased enough to accept a lower level message.
We now eliminate this risk by introducing a counter for each importance
priority. When a message is sent, we check only the queue level for that
particular message's priority. If that is ok, the message can be added
to the backlog, irrespective of the queue level for other priorities.
This way, each level is guaranteed a certain portion of the total
bandwidth, and any risk of starvation is eliminated.
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-25 16:07:24 +00:00
|
|
|
link->window))
|
2014-11-20 09:29:12 +00:00
|
|
|
goto prop_msg_full;
|
|
|
|
if (nla_put_u32(msg->skb, TIPC_NLA_PROP_PRIO, link->priority))
|
|
|
|
goto prop_msg_full;
|
|
|
|
nla_nest_end(msg->skb, prop);
|
|
|
|
|
|
|
|
err = __tipc_nl_add_stats(msg->skb, &link->stats);
|
|
|
|
if (err)
|
|
|
|
goto attr_msg_full;
|
|
|
|
|
|
|
|
nla_nest_end(msg->skb, attrs);
|
|
|
|
genlmsg_end(msg->skb, hdr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
prop_msg_full:
|
|
|
|
nla_nest_cancel(msg->skb, prop);
|
|
|
|
attr_msg_full:
|
|
|
|
nla_nest_cancel(msg->skb, attrs);
|
|
|
|
msg_full:
|
|
|
|
genlmsg_cancel(msg->skb, hdr);
|
|
|
|
|
|
|
|
return -EMSGSIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Caller should hold node lock */
|
2015-01-09 07:27:10 +00:00
|
|
|
static int __tipc_nl_add_node_links(struct net *net, struct tipc_nl_msg *msg,
|
|
|
|
struct tipc_node *node, u32 *prev_link)
|
2014-11-20 09:29:12 +00:00
|
|
|
{
|
|
|
|
u32 i;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
for (i = *prev_link; i < MAX_BEARERS; i++) {
|
|
|
|
*prev_link = i;
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
if (!node->links[i].link)
|
2014-11-20 09:29:12 +00:00
|
|
|
continue;
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
err = __tipc_nl_add_link(net, msg,
|
|
|
|
node->links[i].link, NLM_F_MULTI);
|
2014-11-20 09:29:12 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
*prev_link = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int tipc_nl_link_dump(struct sk_buff *skb, struct netlink_callback *cb)
|
|
|
|
{
|
2015-01-09 07:27:05 +00:00
|
|
|
struct net *net = sock_net(skb->sk);
|
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
2014-11-20 09:29:12 +00:00
|
|
|
struct tipc_node *node;
|
|
|
|
struct tipc_nl_msg msg;
|
|
|
|
u32 prev_node = cb->args[0];
|
|
|
|
u32 prev_link = cb->args[1];
|
|
|
|
int done = cb->args[2];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (done)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
msg.skb = skb;
|
|
|
|
msg.portid = NETLINK_CB(cb->skb).portid;
|
|
|
|
msg.seq = cb->nlh->nlmsg_seq;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
if (prev_node) {
|
2015-01-09 07:27:05 +00:00
|
|
|
node = tipc_node_find(net, prev_node);
|
2014-11-20 09:29:12 +00:00
|
|
|
if (!node) {
|
|
|
|
/* We never set seq or call nl_dump_check_consistent()
|
|
|
|
* this means that setting prev_seq here will cause the
|
|
|
|
* consistence check to fail in the netlink callback
|
|
|
|
* handler. Resulting in the last NLMSG_DONE message
|
|
|
|
* having the NLM_F_DUMP_INTR flag set.
|
|
|
|
*/
|
|
|
|
cb->prev_seq = 1;
|
|
|
|
goto out;
|
|
|
|
}
|
2015-03-26 10:10:24 +00:00
|
|
|
tipc_node_put(node);
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-01-09 07:27:05 +00:00
|
|
|
list_for_each_entry_continue_rcu(node, &tn->node_list,
|
|
|
|
list) {
|
2014-11-20 09:29:12 +00:00
|
|
|
tipc_node_lock(node);
|
2015-01-09 07:27:10 +00:00
|
|
|
err = __tipc_nl_add_node_links(net, &msg, node,
|
|
|
|
&prev_link);
|
2014-11-20 09:29:12 +00:00
|
|
|
tipc_node_unlock(node);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
prev_node = node->addr;
|
|
|
|
}
|
|
|
|
} else {
|
2015-01-09 07:27:07 +00:00
|
|
|
err = tipc_nl_add_bc_link(net, &msg);
|
2014-11-20 09:29:12 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2015-01-09 07:27:05 +00:00
|
|
|
list_for_each_entry_rcu(node, &tn->node_list, list) {
|
2014-11-20 09:29:12 +00:00
|
|
|
tipc_node_lock(node);
|
2015-01-09 07:27:10 +00:00
|
|
|
err = __tipc_nl_add_node_links(net, &msg, node,
|
|
|
|
&prev_link);
|
2014-11-20 09:29:12 +00:00
|
|
|
tipc_node_unlock(node);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
prev_node = node->addr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
done = 1;
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
cb->args[0] = prev_node;
|
|
|
|
cb->args[1] = prev_link;
|
|
|
|
cb->args[2] = done;
|
|
|
|
|
|
|
|
return skb->len;
|
|
|
|
}
|
|
|
|
|
|
|
|
int tipc_nl_link_get(struct sk_buff *skb, struct genl_info *info)
|
|
|
|
{
|
2015-01-09 07:27:05 +00:00
|
|
|
struct net *net = genl_info_net(info);
|
2014-11-20 09:29:12 +00:00
|
|
|
struct tipc_nl_msg msg;
|
|
|
|
char *name;
|
|
|
|
int err;
|
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
msg.portid = info->snd_portid;
|
|
|
|
msg.seq = info->snd_seq;
|
|
|
|
|
2014-11-20 09:29:12 +00:00
|
|
|
if (!info->attrs[TIPC_NLA_LINK_NAME])
|
|
|
|
return -EINVAL;
|
|
|
|
name = nla_data(info->attrs[TIPC_NLA_LINK_NAME]);
|
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
msg.skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
|
|
|
|
if (!msg.skb)
|
2014-11-20 09:29:12 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
if (strcmp(name, tipc_bclink_name) == 0) {
|
|
|
|
err = tipc_nl_add_bc_link(net, &msg);
|
|
|
|
if (err) {
|
|
|
|
nlmsg_free(msg.skb);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
int bearer_id;
|
|
|
|
struct tipc_node *node;
|
|
|
|
struct tipc_link *link;
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
node = tipc_link_find_owner(net, name, &bearer_id);
|
|
|
|
if (!node)
|
|
|
|
return -EINVAL;
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
tipc_node_lock(node);
|
2015-07-16 20:54:19 +00:00
|
|
|
link = node->links[bearer_id].link;
|
2015-05-06 11:58:55 +00:00
|
|
|
if (!link) {
|
|
|
|
tipc_node_unlock(node);
|
|
|
|
nlmsg_free(msg.skb);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
err = __tipc_nl_add_link(net, &msg, link, 0);
|
|
|
|
tipc_node_unlock(node);
|
|
|
|
if (err) {
|
|
|
|
nlmsg_free(msg.skb);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
2014-11-20 09:29:12 +00:00
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
return genlmsg_reply(msg.skb, info);
|
2014-11-20 09:29:12 +00:00
|
|
|
}
|
2014-11-20 09:29:14 +00:00
|
|
|
|
|
|
|
int tipc_nl_link_reset_stats(struct sk_buff *skb, struct genl_info *info)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
char *link_name;
|
|
|
|
unsigned int bearer_id;
|
|
|
|
struct tipc_link *link;
|
|
|
|
struct tipc_node *node;
|
|
|
|
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
|
2015-02-09 08:50:09 +00:00
|
|
|
struct net *net = sock_net(skb->sk);
|
2014-11-20 09:29:14 +00:00
|
|
|
|
|
|
|
if (!info->attrs[TIPC_NLA_LINK])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
err = nla_parse_nested(attrs, TIPC_NLA_LINK_MAX,
|
|
|
|
info->attrs[TIPC_NLA_LINK],
|
|
|
|
tipc_nl_link_policy);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (!attrs[TIPC_NLA_LINK_NAME])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
link_name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
|
|
|
|
|
|
|
|
if (strcmp(link_name, tipc_bclink_name) == 0) {
|
2015-01-09 07:27:07 +00:00
|
|
|
err = tipc_bclink_reset_stats(net);
|
2014-11-20 09:29:14 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-01-09 07:27:05 +00:00
|
|
|
node = tipc_link_find_owner(net, link_name, &bearer_id);
|
2014-11-20 09:29:14 +00:00
|
|
|
if (!node)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
tipc_node_lock(node);
|
|
|
|
|
2015-07-16 20:54:19 +00:00
|
|
|
link = node->links[bearer_id].link;
|
2014-11-20 09:29:14 +00:00
|
|
|
if (!link) {
|
|
|
|
tipc_node_unlock(node);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
link_reset_statistics(link);
|
|
|
|
|
|
|
|
tipc_node_unlock(node);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|