<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt.git/net/tipc, branch test</title>
<subtitle>The LITMUS^RT kernel.</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/'/>
<entry>
<title>tipc: disconnect socket directly after probe failure</title>
<updated>2015-06-11T05:05:20+00:00</updated>
<author>
<name>Erik Hugne</name>
<email>erik.hugne@ericsson.com</email>
</author>
<published>2015-06-09T15:27:12+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=b3be5e3e726a6cc849f40c70c3ae525e4146e9df'/>
<id>b3be5e3e726a6cc849f40c70c3ae525e4146e9df</id>
<content type='text'>
If the TIPC connection timer expires in a probing state, a
self abort message is supposed to be generated and delivered
to the local socket. This is currently broken, and the abort
message is actually sent out to the peer node with invalid
addressing information. This will cause the link to enter
a constant retransmission state and eventually reset.
We fix this by removing the self-abort message creation and
tear down connection immediately instead.

Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Reviewed-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the TIPC connection timer expires in a probing state, a
self abort message is supposed to be generated and delivered
to the local socket. This is currently broken, and the abort
message is actually sent out to the peer node with invalid
addressing information. This will cause the link to enter
a constant retransmission state and eventually reset.
We fix this by removing the self-abort message creation and
tear down connection immediately instead.

Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Reviewed-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: fix problem with parallel link synchronization mechanism</title>
<updated>2015-04-29T19:08:59+00:00</updated>
<author>
<name>Jon Paul Maloy</name>
<email>jon.maloy@ericsson.com</email>
</author>
<published>2015-04-28T20:59:04+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=0d699f28ee5d0641470a603ab5904e463cb1532a'/>
<id>0d699f28ee5d0641470a603ab5904e463cb1532a</id>
<content type='text'>
Currently, we try to accumulate arrived packets in the links's
'deferred' queue during the parallel link syncronization phase.

This entails two problems:

- With an unlucky combination of arriving packets the algorithm
  may go into a lockstep with the out-of-sequence handling function,
  where the synch mechanism is adding a packet to the deferred queue,
  while the out-of-sequence handling is retrieving it again, thus
  ending up in a loop inside the node_lock scope.

- Even if this is avoided, the link will very often send out
  unnecessary protocol messages, in the worst case leading to
  redundant retransmissions.

We fix this by just dropping arriving packets on the upcoming link
during the synchronization phase, thus relying on the retransmission
protocol to resolve the situation once the two links have arrived to
a synchronized state.

Reviewed-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, we try to accumulate arrived packets in the links's
'deferred' queue during the parallel link syncronization phase.

This entails two problems:

- With an unlucky combination of arriving packets the algorithm
  may go into a lockstep with the out-of-sequence handling function,
  where the synch mechanism is adding a packet to the deferred queue,
  while the out-of-sequence handling is retrieving it again, thus
  ending up in a loop inside the node_lock scope.

- Even if this is avoided, the link will very often send out
  unnecessary protocol messages, in the worst case leading to
  redundant retransmissions.

We fix this by just dropping arriving packets on the upcoming link
during the synchronization phase, thus relying on the retransmission
protocol to resolve the situation once the two links have arrived to
a synchronized state.

Reviewed-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: remove wrong use of NLM_F_MULTI</title>
<updated>2015-04-29T18:59:17+00:00</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2015-04-28T16:33:50+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=f2f67390a4b961dae83733732e96e1a394a53c4e'/>
<id>f2f67390a4b961dae83733732e96e1a394a53c4e</id>
<content type='text'>
NLM_F_MULTI must be used only when a NLMSG_DONE message is sent. In fact,
it is sent only at the end of a dump.

Libraries like libnl will wait forever for NLMSG_DONE.

Fixes: 35b9dd7607f0 ("tipc: add bearer get/dump to new netlink api")
Fixes: 7be57fc69184 ("tipc: add link get/dump to new netlink api")
Fixes: 46f15c6794fb ("tipc: add media get/dump to new netlink api")
CC: Richard Alpe &lt;richard.alpe@ericsson.com&gt;
CC: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
CC: Ying Xue &lt;ying.xue@windriver.com&gt;
CC: tipc-discussion@lists.sourceforge.net
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NLM_F_MULTI must be used only when a NLMSG_DONE message is sent. In fact,
it is sent only at the end of a dump.

Libraries like libnl will wait forever for NLMSG_DONE.

Fixes: 35b9dd7607f0 ("tipc: add bearer get/dump to new netlink api")
Fixes: 7be57fc69184 ("tipc: add link get/dump to new netlink api")
Fixes: 46f15c6794fb ("tipc: add media get/dump to new netlink api")
CC: Richard Alpe &lt;richard.alpe@ericsson.com&gt;
CC: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
CC: Ying Xue &lt;ying.xue@windriver.com&gt;
CC: tipc-discussion@lists.sourceforge.net
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: fix node refcount issue</title>
<updated>2015-04-23T15:50:34+00:00</updated>
<author>
<name>Erik Hugne</name>
<email>erik.hugne@ericsson.com</email>
</author>
<published>2015-04-23T13:37:40+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=73a317377303b5ec14d4703d73ba87efffbb779d'/>
<id>73a317377303b5ec14d4703d73ba87efffbb779d</id>
<content type='text'>
When link statistics is dumped over netlink, we iterate over
the list of peer nodes and append each links statistics to
the netlink msg. In the case where the dump is resumed after
filling up a nlmsg, the node refcnt is decremented without
having been incremented previously which may cause the node
reference to be freed. When this happens, the following
info/stacktrace will be generated, followed by a crash or
undefined behavior.
We fix this by removing the erroneous call to tipc_node_put
inside the loop that iterates over nodes.

[  384.312303] INFO: trying to register non-static key.
[  384.313110] the code is fine but needs lockdep annotation.
[  384.313290] turning off the locking correctness validator.
[  384.313290] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0+ #13
[  384.313290] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  384.313290]  ffff88003c6d0290 ffff88003cc03ca8 ffffffff8170adf1 0000000000000007
[  384.313290]  ffffffff82728730 ffff88003cc03d38 ffffffff810a6a6d 00000000001d7200
[  384.313290]  ffff88003c6d0ab0 ffff88003cc03ce8 0000000000000285 0000000000000001
[  384.313290] Call Trace:
[  384.313290]  &lt;IRQ&gt;  [&lt;ffffffff8170adf1&gt;] dump_stack+0x4c/0x65
[  384.313290]  [&lt;ffffffff810a6a6d&gt;] __lock_acquire+0xf3d/0xf50
[  384.313290]  [&lt;ffffffff810a7375&gt;] lock_acquire+0xd5/0x290
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] ? link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffffa0043e70&gt;] ? link_state_event+0x4e0/0x4e0 [tipc]
[  384.313290]  [&lt;ffffffff81712890&gt;] _raw_spin_lock_bh+0x40/0x80
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] ? link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffff810c4698&gt;] call_timer_fn+0xb8/0x490
[  384.313290]  [&lt;ffffffff810c45e0&gt;] ? process_timeout+0x10/0x10
[  384.313290]  [&lt;ffffffff810c5a2c&gt;] run_timer_softirq+0x21c/0x420
[  384.313290]  [&lt;ffffffffa0043e70&gt;] ? link_state_event+0x4e0/0x4e0 [tipc]
[  384.313290]  [&lt;ffffffff8105a954&gt;] __do_softirq+0xf4/0x630
[  384.313290]  [&lt;ffffffff8105afdd&gt;] irq_exit+0x5d/0x60
[  384.313290]  [&lt;ffffffff8103ade1&gt;] smp_apic_timer_interrupt+0x41/0x50
[  384.313290]  [&lt;ffffffff817144a0&gt;] apic_timer_interrupt+0x70/0x80
[  384.313290]  &lt;EOI&gt;  [&lt;ffffffff8100db10&gt;] ? default_idle+0x20/0x210
[  384.313290]  [&lt;ffffffff8100db0e&gt;] ? default_idle+0x1e/0x210
[  384.313290]  [&lt;ffffffff8100e61a&gt;] arch_cpu_idle+0xa/0x10
[  384.313290]  [&lt;ffffffff81099803&gt;] cpu_startup_entry+0x2c3/0x530
[  384.313290]  [&lt;ffffffff810d2893&gt;] ? clockevents_register_device+0x113/0x200
[  384.313290]  [&lt;ffffffff81038b0f&gt;] start_secondary+0x13f/0x170

Fixes: 8a0f6ebe8494 ("tipc: involve reference counter for node structure")
Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When link statistics is dumped over netlink, we iterate over
the list of peer nodes and append each links statistics to
the netlink msg. In the case where the dump is resumed after
filling up a nlmsg, the node refcnt is decremented without
having been incremented previously which may cause the node
reference to be freed. When this happens, the following
info/stacktrace will be generated, followed by a crash or
undefined behavior.
We fix this by removing the erroneous call to tipc_node_put
inside the loop that iterates over nodes.

[  384.312303] INFO: trying to register non-static key.
[  384.313110] the code is fine but needs lockdep annotation.
[  384.313290] turning off the locking correctness validator.
[  384.313290] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0+ #13
[  384.313290] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  384.313290]  ffff88003c6d0290 ffff88003cc03ca8 ffffffff8170adf1 0000000000000007
[  384.313290]  ffffffff82728730 ffff88003cc03d38 ffffffff810a6a6d 00000000001d7200
[  384.313290]  ffff88003c6d0ab0 ffff88003cc03ce8 0000000000000285 0000000000000001
[  384.313290] Call Trace:
[  384.313290]  &lt;IRQ&gt;  [&lt;ffffffff8170adf1&gt;] dump_stack+0x4c/0x65
[  384.313290]  [&lt;ffffffff810a6a6d&gt;] __lock_acquire+0xf3d/0xf50
[  384.313290]  [&lt;ffffffff810a7375&gt;] lock_acquire+0xd5/0x290
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] ? link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffffa0043e70&gt;] ? link_state_event+0x4e0/0x4e0 [tipc]
[  384.313290]  [&lt;ffffffff81712890&gt;] _raw_spin_lock_bh+0x40/0x80
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] ? link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffffa0043e8c&gt;] link_timeout+0x1c/0x170 [tipc]
[  384.313290]  [&lt;ffffffff810c4698&gt;] call_timer_fn+0xb8/0x490
[  384.313290]  [&lt;ffffffff810c45e0&gt;] ? process_timeout+0x10/0x10
[  384.313290]  [&lt;ffffffff810c5a2c&gt;] run_timer_softirq+0x21c/0x420
[  384.313290]  [&lt;ffffffffa0043e70&gt;] ? link_state_event+0x4e0/0x4e0 [tipc]
[  384.313290]  [&lt;ffffffff8105a954&gt;] __do_softirq+0xf4/0x630
[  384.313290]  [&lt;ffffffff8105afdd&gt;] irq_exit+0x5d/0x60
[  384.313290]  [&lt;ffffffff8103ade1&gt;] smp_apic_timer_interrupt+0x41/0x50
[  384.313290]  [&lt;ffffffff817144a0&gt;] apic_timer_interrupt+0x70/0x80
[  384.313290]  &lt;EOI&gt;  [&lt;ffffffff8100db10&gt;] ? default_idle+0x20/0x210
[  384.313290]  [&lt;ffffffff8100db0e&gt;] ? default_idle+0x1e/0x210
[  384.313290]  [&lt;ffffffff8100e61a&gt;] arch_cpu_idle+0xa/0x10
[  384.313290]  [&lt;ffffffff81099803&gt;] cpu_startup_entry+0x2c3/0x530
[  384.313290]  [&lt;ffffffff810d2893&gt;] ? clockevents_register_device+0x113/0x200
[  384.313290]  [&lt;ffffffff81038b0f&gt;] start_secondary+0x13f/0x170

Fixes: 8a0f6ebe8494 ("tipc: involve reference counter for node structure")
Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: fix random link reset problem</title>
<updated>2015-04-23T15:50:34+00:00</updated>
<author>
<name>Erik Hugne</name>
<email>erik.hugne@ericsson.com</email>
</author>
<published>2015-04-23T13:37:39+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=9871b27f6705fc6e0ba633b136369a289b2bfb99'/>
<id>9871b27f6705fc6e0ba633b136369a289b2bfb99</id>
<content type='text'>
In the function tipc_sk_rcv(), the stack variable 'err'
is only initialized to TIPC_ERR_NO_PORT for the first
iteration over the link input queue. If a chain of messages
are received from a link, failure to lookup the socket for
any but the first message will cause the message to bounce back
out on a random link.
We fix this by properly initializing err.

Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the function tipc_sk_rcv(), the stack variable 'err'
is only initialized to TIPC_ERR_NO_PORT for the first
iteration over the link input queue. If a chain of messages
are received from a link, failure to lookup the socket for
any but the first message will cause the message to bounce back
out on a random link.
We fix this by properly initializing err.

Signed-off-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: fix topology server broken issue</title>
<updated>2015-04-23T15:50:34+00:00</updated>
<author>
<name>Ying Xue</name>
<email>ying.xue@windriver.com</email>
</author>
<published>2015-04-23T13:37:38+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=def81f69bfbd70a3278a7592a4ab8717300cbac1'/>
<id>def81f69bfbd70a3278a7592a4ab8717300cbac1</id>
<content type='text'>
When a new topology server is launched in a new namespace, its
listening socket is inserted into the "init ns" namespace's socket
hash table rather than the one owned by the new namespace. Although
the socket's namespace is forcedly changed to the new namespace later,
the socket is still stored in the socket hash table of "init ns"
namespace. When a client created in the new namespace connects
its own topology server, the connection is failed as its server's
socket could not be found from its own namespace's socket table.

If __sock_create() instead of original sock_create_kern() is used
to create the server's socket through specifying an expected namesapce,
the socket will be inserted into the specified namespace's socket
table, thereby avoiding to the topology server broken issue.

Fixes: 76100a8a64bc ("tipc: fix netns refcnt leak")

Reported-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a new topology server is launched in a new namespace, its
listening socket is inserted into the "init ns" namespace's socket
hash table rather than the one owned by the new namespace. Although
the socket's namespace is forcedly changed to the new namespace later,
the socket is still stored in the socket hash table of "init ns"
namespace. When a client created in the new namespace connects
its own topology server, the connection is failed as its server's
socket could not be found from its own namespace's socket table.

If __sock_create() instead of original sock_create_kern() is used
to create the server's socket through specifying an expected namesapce,
the socket will be inserted into the specified namespace's socket
table, thereby avoiding to the topology server broken issue.

Fixes: 76100a8a64bc ("tipc: fix netns refcnt leak")

Reported-by: Erik Hugne &lt;erik.hugne@ericsson.com&gt;
Signed-off-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udp_tunnel: Pass UDP socket down through udp_tunnel{, 6}_xmit_skb().</title>
<updated>2015-04-07T19:29:08+00:00</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-04-06T02:19:09+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=79b16aadea32cce077acbe9e229fcb58a7801687'/>
<id>79b16aadea32cce077acbe9e229fcb58a7801687</id>
<content type='text'>
That was we can make sure the output path of ipv4/ipv6 operate on
the UDP socket rather than whatever random thing happens to be in
skb-&gt;sk.

Based upon a patch by Jiri Pirko.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
That was we can make sure the output path of ipv4/ipv6 operate on
the UDP socket rather than whatever random thing happens to be in
skb-&gt;sk.

Based upon a patch by Jiri Pirko.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: simplify link mtu negotiation</title>
<updated>2015-04-02T20:27:12+00:00</updated>
<author>
<name>Jon Paul Maloy</name>
<email>jon.maloy@ericsson.com</email>
</author>
<published>2015-04-02T13:33:02+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=ed193ece2649c194a87a9d8470195760d367c075'/>
<id>ed193ece2649c194a87a9d8470195760d367c075</id>
<content type='text'>
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 &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: eliminate delayed link deletion at link failover</title>
<updated>2015-04-02T20:27:12+00:00</updated>
<author>
<name>Jon Paul Maloy</name>
<email>jon.maloy@ericsson.com</email>
</author>
<published>2015-04-02T13:33:01+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=dff29b1a88524fe6afe296d6c477c491d1e02af0'/>
<id>dff29b1a88524fe6afe296d6c477c491d1e02af0</id>
<content type='text'>
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 &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tipc: drop tunneled packet duplicates at reception</title>
<updated>2015-04-02T20:27:12+00:00</updated>
<author>
<name>Jon Paul Maloy</name>
<email>jon.maloy@ericsson.com</email>
</author>
<published>2015-04-02T13:33:00+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=2da7142516527a5213588f47ed302e79a5d9527a'/>
<id>2da7142516527a5213588f47ed302e79a5d9527a</id>
<content type='text'>
In commit 8b4ed8634f8b3f9aacfc42b4a872d30c36b9e255
("tipc: eliminate race condition at dual link establishment")
we introduced a parallel link synchronization mechanism that
guarentees sequential delivery even for users switching from
an old to a newly established link. The new mechanism makes it
unnecessary to deliver the tunneled duplicate packets back to
the old link, as we are currently doing. It is now sufficient
to use the last tunneled packet's inner sequence number as
synchronization point between the two parallel links, whereafter
it can be dropped.

In this commit, we drop the duplicate packets arriving on the new
link, after updating the synchronization point at each new arrival.

Although it would now have been sufficient for the other endpoint
to only tunnel the last packet in its send queue, and not the
entire queue, we must still do this to maintain compatibility
with older nodes.

This commit makes it possible to get rid if some complex
interaction between the two parallel links.

Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit 8b4ed8634f8b3f9aacfc42b4a872d30c36b9e255
("tipc: eliminate race condition at dual link establishment")
we introduced a parallel link synchronization mechanism that
guarentees sequential delivery even for users switching from
an old to a newly established link. The new mechanism makes it
unnecessary to deliver the tunneled duplicate packets back to
the old link, as we are currently doing. It is now sufficient
to use the last tunneled packet's inner sequence number as
synchronization point between the two parallel links, whereafter
it can be dropped.

In this commit, we drop the duplicate packets arriving on the new
link, after updating the synchronization point at each new arrival.

Although it would now have been sufficient for the other endpoint
to only tunnel the last packet in its send queue, and not the
entire queue, we must still do this to maintain compatibility
with older nodes.

This commit makes it possible to get rid if some complex
interaction between the two parallel links.

Reviewed-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: Jon Maloy &lt;jon.maloy@ericsson.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
