linux-toradex.git/net/tipc/link.c, branch v3.13-rc2

tipc: fix dereference before check warning

2013-11-15T08:11:06+00:00

This fixes the following Smatch warning:
net/tipc/link.c:2364 tipc_link_recv_fragment()
    warn: variable dereferenced before check '*head' (see line 2361)

A null pointer might be passed to skb_try_coalesce if
a malicious sender injects orphan fragments on a link.

Signed-off-by: Erik Hugne 
Signed-off-by: David S. Miller

tipc: reassembly failures should cause link reset

2013-11-07T23:30:11+00:00

If appending a received fragment to the pending fragment chain
in a unicast link fails, the current code tries to force a retransmission
of the fragment by decrementing the 'next received sequence number'
field in the link. This is done under the assumption that the failure
is caused by an out-of-memory situation, an assumption that does
not hold true after the previous patch in this series.

A failure to append a fragment can now only be caused by a protocol
violation by the sending peer, and it must hence be assumed that it
is either malicious or buggy.  Either way, the correct behavior is now
to reset the link instead of trying to revert its sequence number.
So, this is what we do in this commit.

Signed-off-by: Erik Hugne 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: message reassembly using fragment chain

2013-11-07T23:30:11+00:00

When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last fragment is received, the
reassembled message is delivered upwards to the port/socket layer.

Not only is this an inefficient approach, but it may also cause bursts of
reassembly failures in low memory situations. since we may fail to allocate
the necessary large buffer in the first place. Furthermore, after 100 subsequent
such failures the link will be reset, something that in reality aggravates the
situation.

To remedy this problem, this patch introduces a different approach. Instead of
allocating a big reassembly buffer, we now append the arriving fragments
to a reassembly chain on the link, and deliver the whole chain up to the
socket layer once the last fragment has been received. This is safe because
the retransmission layer of a TIPC link always delivers packets in strict
uninterrupted order, to the reassembly layer as to all other upper layers.
Hence there can never be more than one fragment chain pending reassembly at
any given time in a link, and we can trust (but still verify) that the
fragments will be chained up in the correct order.

Signed-off-by: Erik Hugne 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: don't reroute message fragments

2013-11-07T23:30:11+00:00

When a message fragment is received in a broadcast or unicast link,
the reception code will append the fragment payload to a big reassembly
buffer through a call to the function tipc_recv_fragm(). However, after
the return of that call, the logics goes on and passes the fragment
buffer to the function tipc_net_route_msg(), which will simply drop it.
This behavior is a remnant from the now obsolete multi-cluster
functionality, and has no relevance in the current code base.

Although currently harmless, this unnecessary call would be fatal
after applying the next patch in this series, which introduces
a completely new reassembly algorithm. So we change the code to
eliminate the redundant call.

Signed-off-by: Erik Hugne 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: remove two indentation levels in tipc_recv_msg routine

2013-10-30T20:54:54+00:00

The message dispatching part of tipc_recv_msg() is wrapped layers of
while/if/if/switch, causing out-of-control indentation and does not
look very good. We reduce two indentation levels by separating the
message dispatching from the blocks that checks link state and
sequence numbers, allowing longer function and arg names to be
consistently indented without wrapping. Additionally we also rename
"cont" label to "discard" and add one new label called "unlock_discard"
to make code clearer. In all, these are cosmetic changes that do not
alter the operation of TIPC in any way.

Signed-off-by: Ying Xue 
Reviewed-by: Erik Hugne 
Cc: David Laight 
Cc: Andreas Bofjäll 
Signed-off-by: David S. Miller

tipc: simplify the link lookup routine

2013-10-18T17:20:43+00:00

When checking statistics or changing parameters on a link, the
link_find_link function is used to locate the link with a given
name. The complex method of deconstructing the name into local
and remote address/interface is error prone and may fail if the
interface names contains special characters. We change the lookup
method to iterate over the list of nodes and compare the link
names.

Signed-off-by: Erik Hugne 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: correct return value of link_cmd_set_value routine

2013-10-18T17:20:43+00:00

link_cmd_set_value() takes commands for link, bearer and media related
configuration. Genereally the function returns 0 when a command is
recognized, and -EINVAL when it is not. However, in the switch for link
related commands it returns 0 even when the command is unrecognized. This
will sometimes make it look as if a failed configuration command has been
successful, but has otherwise no negative effects.

We remove this anomaly by returning -EINVAL even for link commands. We also
rework all three switches to make them  conforming to common kernel coding
style.

Signed-off-by: Ying Xue 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: silence sparse warnings

2013-10-18T17:20:42+00:00

Eliminate below sparse warnings:

net/tipc/link.c:1210:37: warning: cast removes address space of expression
net/tipc/link.c:1218:59: warning: incorrect type in argument 2 (different address spaces)
net/tipc/link.c:1218:59:    expected void const [noderef] *from
net/tipc/link.c:1218:59:    got unsigned char const [usertype] *[assigned] sect_crs
net/tipc/socket.c:341:49: warning: Using plain integer as NULL pointer
net/tipc/socket.c:1371:36: warning: Using plain integer as NULL pointer
net/tipc/socket.c:1694:57: warning: Using plain integer as NULL pointer

Signed-off-by: Ying Xue 
Signed-off-by: Andreas Bofjäll 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: remove iovec length parameter from all sending functions

2013-10-18T17:20:42+00:00

tipc_msg_build() now copies message data from iovec to skb_buff
using memcpy_fromiovecend(), which doesn't need to be passed the
iovec length to perform the copying.

So we remove the parameter indicating iovec length in all
functions where TIPC messages are built and sent.

Signed-off-by: Ying Xue 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: fix wrong return value for link_send_sections_long routine

2013-06-17T22:53:01+00:00

When skb buffer cannot be allocated in link_send_sections_long(),
-ENOMEM error code instead of -EFAULT should be returned to its
caller.

Signed-off-by: Ying Xue 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller