2006-01-03 02:04:38 +08:00
|
|
|
/*
|
|
|
|
* net/tipc/msg.c: TIPC message header routines
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2014-05-14 17:39:12 +08:00
|
|
|
* Copyright (c) 2000-2006, 2014, Ericsson AB
|
2011-01-26 02:33:31 +08:00
|
|
|
* Copyright (c) 2005, 2010-2011, Wind River Systems
|
2006-01-03 02:04:38 +08:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
2006-01-11 20:30:43 +08:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
2006-01-03 02:04:38 +08:00
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
2006-01-11 20:30:43 +08: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-03 02:04:38 +08:00
|
|
|
*
|
2006-01-11 20:30:43 +08: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-03 02:04:38 +08:00
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2015-01-09 15:27:04 +08:00
|
|
|
#include <net/sock.h>
|
2006-01-03 02:04:38 +08:00
|
|
|
#include "core.h"
|
|
|
|
#include "msg.h"
|
tipc: introduce message evaluation function
When a message arrives in a node and finds no destination
socket, we may need to drop it, reject it, or forward it after
a secondary destination lookup. The latter two cases currently
results in a code path that is perceived as complex, because it
follows a deep call chain via obscure functions such as
net_route_named_msg() and net_route_msg().
We now introduce a function, tipc_msg_eval(), that takes the
decision about whether such a message should be rejected or
forwarded, but leaves it to the caller to actually perform
the indicated action.
If the decision is 'reject', it is still the task of the recently
introduced function tipc_msg_reverse() to take the final decision
about whether the message is rejectable or not. In the latter case
it drops the message.
As a result of this change, we can finally eliminate the function
net_route_named_msg(), and hence become independent of net_route_msg().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-26 09:41:36 +08:00
|
|
|
#include "addr.h"
|
|
|
|
#include "name_table.h"
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2014-06-26 09:41:35 +08:00
|
|
|
#define MAX_FORWARD_SIZE 1024
|
|
|
|
|
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 09:41:32 +08:00
|
|
|
static unsigned int align(unsigned int i)
|
2010-05-11 22:30:18 +08: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 09:41:32 +08:00
|
|
|
return (i + 3) & ~3u;
|
2010-05-11 22:30:18 +08:00
|
|
|
}
|
|
|
|
|
2015-01-09 15:27:01 +08:00
|
|
|
/**
|
|
|
|
* tipc_buf_acquire - creates a TIPC message buffer
|
|
|
|
* @size: message size (including TIPC header)
|
|
|
|
*
|
|
|
|
* Returns a new buffer with data pointers set to the specified size.
|
|
|
|
*
|
|
|
|
* NOTE: Headroom is reserved to allow prepending of a data link header.
|
|
|
|
* There may also be unrequested tailroom present at the buffer's end.
|
|
|
|
*/
|
|
|
|
struct sk_buff *tipc_buf_acquire(u32 size)
|
|
|
|
{
|
|
|
|
struct sk_buff *skb;
|
|
|
|
unsigned int buf_size = (BUF_HEADROOM + size + 3) & ~3u;
|
|
|
|
|
|
|
|
skb = alloc_skb_fclone(buf_size, GFP_ATOMIC);
|
|
|
|
if (skb) {
|
|
|
|
skb_reserve(skb, BUF_HEADROOM);
|
|
|
|
skb_put(skb, size);
|
|
|
|
skb->next = NULL;
|
|
|
|
}
|
|
|
|
return skb;
|
|
|
|
}
|
|
|
|
|
2013-06-17 22:54:47 +08:00
|
|
|
void tipc_msg_init(struct tipc_msg *m, u32 user, u32 type, u32 hsize,
|
|
|
|
u32 destnode)
|
2010-05-11 22:30:18 +08:00
|
|
|
{
|
|
|
|
memset(m, 0, hsize);
|
|
|
|
msg_set_version(m);
|
|
|
|
msg_set_user(m, user);
|
|
|
|
msg_set_hdr_sz(m, hsize);
|
|
|
|
msg_set_size(m, hsize);
|
|
|
|
msg_set_prevnode(m, tipc_own_addr);
|
|
|
|
msg_set_type(m, type);
|
2014-08-23 06:09:06 +08:00
|
|
|
if (hsize > SHORT_H_SIZE) {
|
|
|
|
msg_set_orignode(m, tipc_own_addr);
|
|
|
|
msg_set_destnode(m, destnode);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
struct sk_buff *tipc_msg_create(uint user, uint type, uint hdr_sz,
|
|
|
|
uint data_sz, u32 dnode, u32 onode,
|
|
|
|
u32 dport, u32 oport, int errcode)
|
|
|
|
{
|
|
|
|
struct tipc_msg *msg;
|
|
|
|
struct sk_buff *buf;
|
|
|
|
|
|
|
|
buf = tipc_buf_acquire(hdr_sz + data_sz);
|
|
|
|
if (unlikely(!buf))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
msg = buf_msg(buf);
|
|
|
|
tipc_msg_init(msg, user, type, hdr_sz, dnode);
|
|
|
|
msg_set_size(msg, hdr_sz + data_sz);
|
|
|
|
msg_set_prevnode(msg, onode);
|
|
|
|
msg_set_origport(msg, oport);
|
|
|
|
msg_set_destport(msg, dport);
|
|
|
|
msg_set_errcode(msg, errcode);
|
|
|
|
if (hdr_sz > SHORT_H_SIZE) {
|
|
|
|
msg_set_orignode(msg, onode);
|
|
|
|
msg_set_destnode(msg, dnode);
|
|
|
|
}
|
|
|
|
return buf;
|
2010-05-11 22:30:18 +08:00
|
|
|
}
|
|
|
|
|
2014-05-14 17:39:12 +08:00
|
|
|
/* tipc_buf_append(): Append a buffer to the fragment list of another buffer
|
2014-07-06 01:44:13 +08:00
|
|
|
* @*headbuf: in: NULL for first frag, otherwise value returned from prev call
|
|
|
|
* out: set when successful non-complete reassembly, otherwise NULL
|
|
|
|
* @*buf: in: the buffer to append. Always defined
|
2014-10-30 13:58:51 +08:00
|
|
|
* out: head buf after successful complete reassembly, otherwise NULL
|
2014-07-06 01:44:13 +08:00
|
|
|
* Returns 1 when reassembly complete, otherwise 0
|
2014-05-14 17:39:12 +08:00
|
|
|
*/
|
|
|
|
int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
|
|
|
|
{
|
|
|
|
struct sk_buff *head = *headbuf;
|
|
|
|
struct sk_buff *frag = *buf;
|
|
|
|
struct sk_buff *tail;
|
2014-07-26 02:48:09 +08:00
|
|
|
struct tipc_msg *msg;
|
|
|
|
u32 fragid;
|
2014-05-14 17:39:12 +08:00
|
|
|
int delta;
|
2014-07-26 02:48:09 +08:00
|
|
|
bool headstolen;
|
2014-05-14 17:39:12 +08:00
|
|
|
|
2014-07-26 02:48:09 +08:00
|
|
|
if (!frag)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
msg = buf_msg(frag);
|
|
|
|
fragid = msg_type(msg);
|
|
|
|
frag->next = NULL;
|
2014-05-14 17:39:12 +08:00
|
|
|
skb_pull(frag, msg_hdr_sz(msg));
|
|
|
|
|
|
|
|
if (fragid == FIRST_FRAGMENT) {
|
2014-07-26 02:48:09 +08:00
|
|
|
if (unlikely(head))
|
|
|
|
goto err;
|
|
|
|
if (unlikely(skb_unclone(frag, GFP_ATOMIC)))
|
|
|
|
goto err;
|
2014-05-14 17:39:12 +08:00
|
|
|
head = *headbuf = frag;
|
|
|
|
skb_frag_list_init(head);
|
2014-07-26 02:48:09 +08:00
|
|
|
TIPC_SKB_CB(head)->tail = NULL;
|
2014-07-06 01:44:13 +08:00
|
|
|
*buf = NULL;
|
2014-05-14 17:39:12 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2014-07-26 02:48:09 +08:00
|
|
|
|
2014-05-14 17:39:12 +08:00
|
|
|
if (!head)
|
2014-07-26 02:48:09 +08:00
|
|
|
goto err;
|
|
|
|
|
2014-05-14 17:39:12 +08:00
|
|
|
if (skb_try_coalesce(head, frag, &headstolen, &delta)) {
|
|
|
|
kfree_skb_partial(frag, headstolen);
|
|
|
|
} else {
|
2014-07-26 02:48:09 +08:00
|
|
|
tail = TIPC_SKB_CB(head)->tail;
|
2014-05-14 17:39:12 +08:00
|
|
|
if (!skb_has_frag_list(head))
|
|
|
|
skb_shinfo(head)->frag_list = frag;
|
|
|
|
else
|
|
|
|
tail->next = frag;
|
|
|
|
head->truesize += frag->truesize;
|
|
|
|
head->data_len += frag->len;
|
|
|
|
head->len += frag->len;
|
|
|
|
TIPC_SKB_CB(head)->tail = frag;
|
|
|
|
}
|
2014-07-26 02:48:09 +08:00
|
|
|
|
2014-05-14 17:39:12 +08:00
|
|
|
if (fragid == LAST_FRAGMENT) {
|
|
|
|
*buf = head;
|
|
|
|
TIPC_SKB_CB(head)->tail = NULL;
|
|
|
|
*headbuf = NULL;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
*buf = NULL;
|
|
|
|
return 0;
|
2014-07-26 02:48:09 +08:00
|
|
|
|
|
|
|
err:
|
2014-05-14 17:39:12 +08:00
|
|
|
pr_warn_ratelimited("Unable to build fragment list\n");
|
|
|
|
kfree_skb(*buf);
|
2014-07-06 01:44:13 +08:00
|
|
|
kfree_skb(*headbuf);
|
|
|
|
*buf = *headbuf = NULL;
|
2014-05-14 17:39:12 +08:00
|
|
|
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 09:41:32 +08:00
|
|
|
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
|
|
|
|
/**
|
2014-07-17 08:41:03 +08:00
|
|
|
* tipc_msg_build - create buffer chain containing specified header and data
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
* @mhdr: Message header, to be prepended to data
|
2014-11-15 14:16:27 +08:00
|
|
|
* @m: User message
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
* @offset: Posision in iov to start copying from
|
|
|
|
* @dsz: Total length of user data
|
|
|
|
* @pktmax: Max packet size that can be used
|
2014-11-26 11:41:55 +08:00
|
|
|
* @list: Buffer or chain of buffers to be returned to caller
|
|
|
|
*
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
* Returns message data size or errno: -ENOMEM, -EFAULT
|
|
|
|
*/
|
2014-11-26 11:41:55 +08:00
|
|
|
int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m, int offset,
|
|
|
|
int dsz, int pktmax, struct sk_buff_head *list)
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
{
|
|
|
|
int mhsz = msg_hdr_sz(mhdr);
|
|
|
|
int msz = mhsz + dsz;
|
|
|
|
int pktno = 1;
|
|
|
|
int pktsz;
|
|
|
|
int pktrem = pktmax;
|
|
|
|
int drem = dsz;
|
|
|
|
struct tipc_msg pkthdr;
|
2014-11-26 11:41:55 +08:00
|
|
|
struct sk_buff *skb;
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
char *pktpos;
|
|
|
|
int rc;
|
2014-11-26 11:41:55 +08:00
|
|
|
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
msg_set_size(mhdr, msz);
|
|
|
|
|
|
|
|
/* No fragmentation needed? */
|
|
|
|
if (likely(msz <= pktmax)) {
|
2014-11-26 11:41:55 +08:00
|
|
|
skb = tipc_buf_acquire(msz);
|
|
|
|
if (unlikely(!skb))
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
return -ENOMEM;
|
2015-01-09 15:27:04 +08:00
|
|
|
skb_orphan(skb);
|
2014-11-26 11:41:55 +08:00
|
|
|
__skb_queue_tail(list, skb);
|
|
|
|
skb_copy_to_linear_data(skb, mhdr, mhsz);
|
|
|
|
pktpos = skb->data + mhsz;
|
2014-11-24 23:42:55 +08:00
|
|
|
if (!dsz || !memcpy_fromiovecend(pktpos, m->msg_iter.iov, offset,
|
2014-11-26 11:41:55 +08:00
|
|
|
dsz))
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
return dsz;
|
|
|
|
rc = -EFAULT;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Prepare reusable fragment header */
|
|
|
|
tipc_msg_init(&pkthdr, MSG_FRAGMENTER, FIRST_FRAGMENT,
|
|
|
|
INT_H_SIZE, msg_destnode(mhdr));
|
|
|
|
msg_set_size(&pkthdr, pktmax);
|
|
|
|
msg_set_fragm_no(&pkthdr, pktno);
|
|
|
|
|
|
|
|
/* Prepare first fragment */
|
2014-11-26 11:41:55 +08:00
|
|
|
skb = tipc_buf_acquire(pktmax);
|
|
|
|
if (!skb)
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
return -ENOMEM;
|
2015-01-09 15:27:04 +08:00
|
|
|
skb_orphan(skb);
|
2014-11-26 11:41:55 +08:00
|
|
|
__skb_queue_tail(list, skb);
|
|
|
|
pktpos = skb->data;
|
|
|
|
skb_copy_to_linear_data(skb, &pkthdr, INT_H_SIZE);
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
pktpos += INT_H_SIZE;
|
|
|
|
pktrem -= INT_H_SIZE;
|
2014-11-26 11:41:55 +08:00
|
|
|
skb_copy_to_linear_data_offset(skb, INT_H_SIZE, mhdr, mhsz);
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
pktpos += mhsz;
|
|
|
|
pktrem -= mhsz;
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (drem < pktrem)
|
|
|
|
pktrem = drem;
|
|
|
|
|
2014-11-24 23:42:55 +08:00
|
|
|
if (memcpy_fromiovecend(pktpos, m->msg_iter.iov, offset, pktrem)) {
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
rc = -EFAULT;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
drem -= pktrem;
|
|
|
|
offset += pktrem;
|
|
|
|
|
|
|
|
if (!drem)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Prepare new fragment: */
|
|
|
|
if (drem < (pktmax - INT_H_SIZE))
|
|
|
|
pktsz = drem + INT_H_SIZE;
|
|
|
|
else
|
|
|
|
pktsz = pktmax;
|
2014-11-26 11:41:55 +08:00
|
|
|
skb = tipc_buf_acquire(pktsz);
|
|
|
|
if (!skb) {
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
rc = -ENOMEM;
|
|
|
|
goto error;
|
|
|
|
}
|
2015-01-09 15:27:04 +08:00
|
|
|
skb_orphan(skb);
|
2014-11-26 11:41:55 +08:00
|
|
|
__skb_queue_tail(list, skb);
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
msg_set_type(&pkthdr, FRAGMENT);
|
|
|
|
msg_set_size(&pkthdr, pktsz);
|
|
|
|
msg_set_fragm_no(&pkthdr, ++pktno);
|
2014-11-26 11:41:55 +08:00
|
|
|
skb_copy_to_linear_data(skb, &pkthdr, INT_H_SIZE);
|
|
|
|
pktpos = skb->data + INT_H_SIZE;
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
pktrem = pktsz - INT_H_SIZE;
|
|
|
|
|
|
|
|
} while (1);
|
2014-11-26 11:41:55 +08:00
|
|
|
msg_set_type(buf_msg(skb), LAST_FRAGMENT);
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
return dsz;
|
|
|
|
error:
|
2014-11-26 11:41:55 +08:00
|
|
|
__skb_queue_purge(list);
|
|
|
|
__skb_queue_head_init(list);
|
tipc: introduce direct iovec to buffer chain fragmentation function
Fragmentation at message sending is currently performed in two
places in link.c, depending on whether data to be transmitted
is delivered in the form of an iovec or as a big sk_buff. Those
functions are also tightly entangled with the send functions
that are using them.
We now introduce a re-entrant, standalone function, tipc_msg_build2(),
that builds a packet chain directly from an iovec. Each fragment is
sized according to the MTU value given by the caller, and is prepended
with a correctly built fragment header, when needed. The function is
independent from who is calling and where the chain will be delivered,
as long as the caller is able to indicate a correct MTU.
The function is tested, but not called by anybody yet. Since it is
incompatible with the existing tipc_msg_build(), and we cannot yet
remove that function, we have given it a temporary name.
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 09:41:34 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
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 09:41:32 +08:00
|
|
|
/**
|
|
|
|
* tipc_msg_bundle(): Append contents of a buffer to tail of an existing one
|
2014-11-26 11:41:52 +08:00
|
|
|
* @list: the buffer chain of the existing buffer ("bundle")
|
|
|
|
* @skb: buffer to be appended
|
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 09:41:32 +08:00
|
|
|
* @mtu: max allowable size for the bundle buffer
|
|
|
|
* Consumes buffer if successful
|
|
|
|
* Returns true if bundling could be performed, otherwise false
|
|
|
|
*/
|
2014-11-26 11:41:52 +08:00
|
|
|
bool tipc_msg_bundle(struct sk_buff_head *list, struct sk_buff *skb, u32 mtu)
|
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 09:41:32 +08:00
|
|
|
{
|
2014-11-26 11:41:52 +08:00
|
|
|
struct sk_buff *bskb = skb_peek_tail(list);
|
|
|
|
struct tipc_msg *bmsg = buf_msg(bskb);
|
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
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 09:41:32 +08:00
|
|
|
unsigned int bsz = msg_size(bmsg);
|
|
|
|
unsigned int msz = msg_size(msg);
|
|
|
|
u32 start = align(bsz);
|
|
|
|
u32 max = mtu - INT_H_SIZE;
|
|
|
|
u32 pad = start - bsz;
|
|
|
|
|
|
|
|
if (likely(msg_user(msg) == MSG_FRAGMENTER))
|
|
|
|
return false;
|
|
|
|
if (unlikely(msg_user(msg) == CHANGEOVER_PROTOCOL))
|
|
|
|
return false;
|
|
|
|
if (unlikely(msg_user(msg) == BCAST_PROTOCOL))
|
|
|
|
return false;
|
|
|
|
if (likely(msg_user(bmsg) != MSG_BUNDLER))
|
|
|
|
return false;
|
2014-11-26 11:41:52 +08:00
|
|
|
if (likely(!TIPC_SKB_CB(bskb)->bundling))
|
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 09:41:32 +08:00
|
|
|
return false;
|
2014-11-26 11:41:52 +08:00
|
|
|
if (unlikely(skb_tailroom(bskb) < (pad + msz)))
|
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 09:41:32 +08:00
|
|
|
return false;
|
|
|
|
if (unlikely(max < (start + msz)))
|
|
|
|
return false;
|
|
|
|
|
2014-11-26 11:41:52 +08:00
|
|
|
skb_put(bskb, pad + msz);
|
|
|
|
skb_copy_to_linear_data_offset(bskb, start, skb->data, msz);
|
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 09:41:32 +08:00
|
|
|
msg_set_size(bmsg, start + msz);
|
|
|
|
msg_set_msgcnt(bmsg, msg_msgcnt(bmsg) + 1);
|
2014-11-26 11:41:52 +08:00
|
|
|
kfree_skb(skb);
|
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 09:41:32 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_msg_make_bundle(): Create bundle buf and append message to its tail
|
2014-11-26 11:41:52 +08:00
|
|
|
* @list: the buffer chain
|
|
|
|
* @skb: buffer to be appended and replaced
|
|
|
|
* @mtu: max allowable size for the bundle buffer, inclusive header
|
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 09:41:32 +08:00
|
|
|
* @dnode: destination node for message. (Not always present in header)
|
|
|
|
* Replaces buffer if successful
|
2014-10-30 13:58:51 +08:00
|
|
|
* Returns true if success, otherwise false
|
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 09:41:32 +08:00
|
|
|
*/
|
2014-11-26 11:41:52 +08:00
|
|
|
bool tipc_msg_make_bundle(struct sk_buff_head *list, struct sk_buff *skb,
|
|
|
|
u32 mtu, u32 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 09:41:32 +08:00
|
|
|
{
|
2014-11-26 11:41:52 +08:00
|
|
|
struct sk_buff *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 09:41:32 +08:00
|
|
|
struct tipc_msg *bmsg;
|
2014-11-26 11:41:52 +08:00
|
|
|
struct tipc_msg *msg = buf_msg(skb);
|
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 09:41:32 +08:00
|
|
|
u32 msz = msg_size(msg);
|
|
|
|
u32 max = mtu - INT_H_SIZE;
|
|
|
|
|
|
|
|
if (msg_user(msg) == MSG_FRAGMENTER)
|
|
|
|
return false;
|
|
|
|
if (msg_user(msg) == CHANGEOVER_PROTOCOL)
|
|
|
|
return false;
|
|
|
|
if (msg_user(msg) == BCAST_PROTOCOL)
|
|
|
|
return false;
|
|
|
|
if (msz > (max / 2))
|
|
|
|
return false;
|
|
|
|
|
2014-11-26 11:41:52 +08:00
|
|
|
bskb = tipc_buf_acquire(max);
|
|
|
|
if (!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 09:41:32 +08:00
|
|
|
return false;
|
|
|
|
|
2014-11-26 11:41:52 +08:00
|
|
|
skb_trim(bskb, INT_H_SIZE);
|
|
|
|
bmsg = buf_msg(bskb);
|
2014-11-26 11:41:49 +08:00
|
|
|
tipc_msg_init(bmsg, MSG_BUNDLER, 0, INT_H_SIZE, 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 09:41:32 +08:00
|
|
|
msg_set_seqno(bmsg, msg_seqno(msg));
|
|
|
|
msg_set_ack(bmsg, msg_ack(msg));
|
|
|
|
msg_set_bcast_ack(bmsg, msg_bcast_ack(msg));
|
2014-11-26 11:41:52 +08:00
|
|
|
TIPC_SKB_CB(bskb)->bundling = true;
|
|
|
|
__skb_queue_tail(list, bskb);
|
|
|
|
return tipc_msg_bundle(list, skb, mtu);
|
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 09:41:32 +08:00
|
|
|
}
|
2014-06-26 09:41:35 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_msg_reverse(): swap source and destination addresses and add error code
|
|
|
|
* @buf: buffer containing message to be reversed
|
|
|
|
* @dnode: return value: node where to send message after reversal
|
|
|
|
* @err: error code to be set in message
|
|
|
|
* Consumes buffer if failure
|
|
|
|
* Returns true if success, otherwise false
|
|
|
|
*/
|
|
|
|
bool tipc_msg_reverse(struct sk_buff *buf, u32 *dnode, int err)
|
|
|
|
{
|
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
|
|
|
uint imp = msg_importance(msg);
|
|
|
|
struct tipc_msg ohdr;
|
|
|
|
uint rdsz = min_t(uint, msg_data_sz(msg), MAX_FORWARD_SIZE);
|
|
|
|
|
2014-06-26 09:41:41 +08:00
|
|
|
if (skb_linearize(buf))
|
2014-06-26 09:41:35 +08:00
|
|
|
goto exit;
|
2014-06-26 09:41:41 +08:00
|
|
|
if (msg_dest_droppable(msg))
|
|
|
|
goto exit;
|
|
|
|
if (msg_errcode(msg))
|
2014-06-26 09:41:35 +08:00
|
|
|
goto exit;
|
|
|
|
|
|
|
|
memcpy(&ohdr, msg, msg_hdr_sz(msg));
|
2014-06-26 09:41:41 +08:00
|
|
|
imp = min_t(uint, imp + 1, TIPC_CRITICAL_IMPORTANCE);
|
|
|
|
if (msg_isdata(msg))
|
|
|
|
msg_set_importance(msg, imp);
|
2014-06-26 09:41:35 +08:00
|
|
|
msg_set_errcode(msg, err);
|
|
|
|
msg_set_origport(msg, msg_destport(&ohdr));
|
|
|
|
msg_set_destport(msg, msg_origport(&ohdr));
|
|
|
|
msg_set_prevnode(msg, tipc_own_addr);
|
|
|
|
if (!msg_short(msg)) {
|
|
|
|
msg_set_orignode(msg, msg_destnode(&ohdr));
|
|
|
|
msg_set_destnode(msg, msg_orignode(&ohdr));
|
|
|
|
}
|
|
|
|
msg_set_size(msg, msg_hdr_sz(msg) + rdsz);
|
|
|
|
skb_trim(buf, msg_size(msg));
|
|
|
|
skb_orphan(buf);
|
|
|
|
*dnode = msg_orignode(&ohdr);
|
|
|
|
return true;
|
|
|
|
exit:
|
|
|
|
kfree_skb(buf);
|
|
|
|
return false;
|
|
|
|
}
|
tipc: introduce message evaluation function
When a message arrives in a node and finds no destination
socket, we may need to drop it, reject it, or forward it after
a secondary destination lookup. The latter two cases currently
results in a code path that is perceived as complex, because it
follows a deep call chain via obscure functions such as
net_route_named_msg() and net_route_msg().
We now introduce a function, tipc_msg_eval(), that takes the
decision about whether such a message should be rejected or
forwarded, but leaves it to the caller to actually perform
the indicated action.
If the decision is 'reject', it is still the task of the recently
introduced function tipc_msg_reverse() to take the final decision
about whether the message is rejectable or not. In the latter case
it drops the message.
As a result of this change, we can finally eliminate the function
net_route_named_msg(), and hence become independent of net_route_msg().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-26 09:41:36 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_msg_eval: determine fate of message that found no destination
|
|
|
|
* @buf: the buffer containing the message.
|
|
|
|
* @dnode: return value: next-hop node, if message to be forwarded
|
|
|
|
* @err: error code to use, if message to be rejected
|
|
|
|
*
|
|
|
|
* Does not consume buffer
|
|
|
|
* Returns 0 (TIPC_OK) if message ok and we can try again, -TIPC error
|
|
|
|
* code if message to be rejected
|
|
|
|
*/
|
2015-01-09 15:27:09 +08:00
|
|
|
int tipc_msg_eval(struct net *net, struct sk_buff *buf, u32 *dnode)
|
tipc: introduce message evaluation function
When a message arrives in a node and finds no destination
socket, we may need to drop it, reject it, or forward it after
a secondary destination lookup. The latter two cases currently
results in a code path that is perceived as complex, because it
follows a deep call chain via obscure functions such as
net_route_named_msg() and net_route_msg().
We now introduce a function, tipc_msg_eval(), that takes the
decision about whether such a message should be rejected or
forwarded, but leaves it to the caller to actually perform
the indicated action.
If the decision is 'reject', it is still the task of the recently
introduced function tipc_msg_reverse() to take the final decision
about whether the message is rejectable or not. In the latter case
it drops the message.
As a result of this change, we can finally eliminate the function
net_route_named_msg(), and hence become independent of net_route_msg().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-26 09:41:36 +08:00
|
|
|
{
|
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
|
|
|
u32 dport;
|
|
|
|
|
|
|
|
if (msg_type(msg) != TIPC_NAMED_MSG)
|
|
|
|
return -TIPC_ERR_NO_PORT;
|
|
|
|
if (skb_linearize(buf))
|
|
|
|
return -TIPC_ERR_NO_NAME;
|
|
|
|
if (msg_data_sz(msg) > MAX_FORWARD_SIZE)
|
|
|
|
return -TIPC_ERR_NO_NAME;
|
|
|
|
if (msg_reroute_cnt(msg) > 0)
|
|
|
|
return -TIPC_ERR_NO_NAME;
|
|
|
|
|
|
|
|
*dnode = addr_domain(msg_lookup_scope(msg));
|
2015-01-09 15:27:09 +08:00
|
|
|
dport = tipc_nametbl_translate(net, msg_nametype(msg),
|
tipc: introduce message evaluation function
When a message arrives in a node and finds no destination
socket, we may need to drop it, reject it, or forward it after
a secondary destination lookup. The latter two cases currently
results in a code path that is perceived as complex, because it
follows a deep call chain via obscure functions such as
net_route_named_msg() and net_route_msg().
We now introduce a function, tipc_msg_eval(), that takes the
decision about whether such a message should be rejected or
forwarded, but leaves it to the caller to actually perform
the indicated action.
If the decision is 'reject', it is still the task of the recently
introduced function tipc_msg_reverse() to take the final decision
about whether the message is rejectable or not. In the latter case
it drops the message.
As a result of this change, we can finally eliminate the function
net_route_named_msg(), and hence become independent of net_route_msg().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-26 09:41:36 +08:00
|
|
|
msg_nameinst(msg),
|
|
|
|
dnode);
|
|
|
|
if (!dport)
|
|
|
|
return -TIPC_ERR_NO_NAME;
|
|
|
|
msg_incr_reroute_cnt(msg);
|
|
|
|
msg_set_destnode(msg, *dnode);
|
|
|
|
msg_set_destport(msg, dport);
|
|
|
|
return TIPC_OK;
|
|
|
|
}
|
2014-07-17 08:41:00 +08:00
|
|
|
|
|
|
|
/* tipc_msg_reassemble() - clone a buffer chain of fragments and
|
|
|
|
* reassemble the clones into one message
|
|
|
|
*/
|
2014-11-26 11:41:55 +08:00
|
|
|
struct sk_buff *tipc_msg_reassemble(struct sk_buff_head *list)
|
2014-07-17 08:41:00 +08:00
|
|
|
{
|
2014-11-26 11:41:55 +08:00
|
|
|
struct sk_buff *skb;
|
|
|
|
struct sk_buff *frag = NULL;
|
2014-07-17 08:41:00 +08:00
|
|
|
struct sk_buff *head = NULL;
|
|
|
|
int hdr_sz;
|
|
|
|
|
|
|
|
/* Copy header if single buffer */
|
2014-11-26 11:41:55 +08:00
|
|
|
if (skb_queue_len(list) == 1) {
|
|
|
|
skb = skb_peek(list);
|
|
|
|
hdr_sz = skb_headroom(skb) + msg_hdr_sz(buf_msg(skb));
|
|
|
|
return __pskb_copy(skb, hdr_sz, GFP_ATOMIC);
|
2014-07-17 08:41:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Clone all fragments and reassemble */
|
2014-11-26 11:41:55 +08:00
|
|
|
skb_queue_walk(list, skb) {
|
|
|
|
frag = skb_clone(skb, GFP_ATOMIC);
|
2014-07-17 08:41:00 +08:00
|
|
|
if (!frag)
|
|
|
|
goto error;
|
|
|
|
frag->next = NULL;
|
|
|
|
if (tipc_buf_append(&head, &frag))
|
|
|
|
break;
|
|
|
|
if (!head)
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
return frag;
|
|
|
|
error:
|
|
|
|
pr_warn("Failed do clone local mcast rcv buffer\n");
|
|
|
|
kfree_skb(head);
|
|
|
|
return NULL;
|
|
|
|
}
|