On 12/06/2013 12:45 PM, David Miller wrote:
From: Zhi Yong Wu zwu.ker...@gmail.com
Date: Fri, 6 Dec 2013 17:08:50 +0800
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
Also applied and queued up for -stable, thanks.
I noticed in these
On 12/06/2013 03:54 PM, Zhi Yong Wu wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
By checking related codes, it is impossible that ret len or total_len,
so we should remove some useless coeds in both above functions.
Looks like commit 6680ec68eff47d36f67b4351bc9836fd6cba9532
Author:
On 12/04/2013 11:25 AM, Michael Tuexen wrote:
> On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
>
>> On 12/04/2013 11:01 AM, Michael Tuexen wrote:
>>> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote:
>>>
>>>> On 12/04/2013 09:50 AM, David Laight wrot
On 12/04/2013 12:57 PM, Sun Paul wrote:
> As I know, the A to C and A to D case must have a router in between to form
> SCTP multihome topology.
Not necessary. I've produced proper multihoming topologies with just
VLANs and different subnet assignment. You can even remove VLANs
if you correctly
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote:
>
>> On 12/04/2013 09:50 AM, David Laight wrote:
>>>>> In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
>>>>> IP-A. IP-A then sends
On 12/04/2013 09:50 AM, David Laight wrote:
>>> In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
>>> IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
>>> the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK.
>>>
>>> In case of the path between IP-A
m the same address that
HB were sent to. This is because HB contains a nonce and that nonce
is used to locate the correct transport that this HB-ACK belongs to.
So, yes, the above communication is a valid SCTP exchange.
-vlad
>
> On Tue, Dec 3, 2013 at 11:22 PM, Vlad Yasevich wrote:
>
is used to locate the correct transport that this HB-ACK belongs to.
So, yes, the above communication is a valid SCTP exchange.
-vlad
On Tue, Dec 3, 2013 at 11:22 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/03/2013 08:11 AM, Sun Paul wrote:
But how about the HB and HB_ACK? Still valid
On 12/04/2013 09:50 AM, David Laight wrote:
In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK.
In case of the path between IP-A and IP-X is
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 09:50 AM, David Laight wrote:
In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK
On 12/04/2013 12:57 PM, Sun Paul wrote:
As I know, the A to C and A to D case must have a router in between to form
SCTP multihome topology.
Not necessary. I've produced proper multihoming topologies with just
VLANs and different subnet assignment. You can even remove VLANs
if you correctly
On 12/04/2013 11:25 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 09:50 AM, David Laight wrote:
In normal
On 12/03/2013 08:11 AM, Sun Paul wrote:
> But how about the HB and HB_ACK? Still valid?
As long as the source address is part of the association, then yes
it is perfectly valid.
-vlad
> On Dec 3, 2013 8:32 PM, "Vlad Yasevich" wrote:
>
>> On 12/02/2013 09:19 P
st of the INIT-ACK
chunk, yes.
There is the code in __sctp_rcv_lookup_harder() that looks for other
adddresses in the INIT and INIT-ACK chunks.
-vlad
>
>
> On Tue, Dec 3, 2013 at 10:03 AM, Vlad Yasevich wrote:
>> On 12/02/2013 08:39 PM, Sun Paul wrote:
>>> Another question
, yes.
There is the code in __sctp_rcv_lookup_harder() that looks for other
adddresses in the INIT and INIT-ACK chunks.
-vlad
On Tue, Dec 3, 2013 at 10:03 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/02/2013 08:39 PM, Sun Paul wrote:
Another question
if a wrong source IP is used, does
On 12/03/2013 08:11 AM, Sun Paul wrote:
But how about the HB and HB_ACK? Still valid?
As long as the source address is part of the association, then yes
it is perfectly valid.
-vlad
On Dec 3, 2013 8:32 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/02/2013 09:19 PM, Sun Paul wrote
.1.1.254 dev eth2
>> cache mtu 1500 advmss 1460 hoplimit 64
>>
>> [root@localhost ~]# ip route get 12.1.1.1 from 110.1.1.1
>> 12.1.1.1 from 110.1.1.1 via 110.1.1.254 dev eth1
>> cache mtu 1500 advmss 1460 hoplimit 64
>>
>> so, if this is not b
ip route get 11.1.1.1 return?
That's the address that will be used to talk to 11.1.1.1 by default.
-vlad
>
> On Tue, Dec 3, 2013 at 12:42 AM, Vlad Yasevich wrote:
>> On 12/02/2013 10:45 AM, Karl Heiss wrote:
>>> On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich wrote:
>>&
On 12/02/2013 10:45 AM, Karl Heiss wrote:
> On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich wrote:
>> On 11/27/2013 11:03 PM, Sun Paul wrote:
>>> How LKSCTP select which source address to use for the INIT_ACK or
>>> HB_ACK? below is the testing result where a router i
>>> - PS
>>>
>>> On Wed, Nov 27, 2013 at 7:09 AM, Sun Paul wrote:
>>>> Hi Vlad
>>>>
>>>> Thank for your reply. If it is based on the destination IP to find the
>>>> best route, why the problem didn't happen on single-homing
to use the interface eth1 to
respond to the SCTP request.
- PS
On Tue, Nov 26, 2013 at 11:19 PM, Vlad Yasevich vyasev...@gmail.com
wrote:
On 11/25/2013 08:03 PM, Sun Paul wrote:
Hi
we have a problem on using LKSCTP to form a 4 ways multi-homing network.
Configuration
- Node-A has 2 IP
On 12/02/2013 10:45 AM, Karl Heiss wrote:
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 11/27/2013 11:03 PM, Sun Paul wrote:
How LKSCTP select which source address to use for the INIT_ACK or
HB_ACK? below is the testing result where a router is located
by default.
-vlad
On Tue, Dec 3, 2013 at 12:42 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/02/2013 10:45 AM, Karl Heiss wrote:
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 11/27/2013 11:03 PM, Sun Paul wrote:
How LKSCTP select which source address to use
110.1.1.1
12.1.1.1 from 110.1.1.1 via 110.1.1.254 dev eth1
cache mtu 1500 advmss 1460 hoplimit 64
so, if this is not being handled in LKSCTP, is it possible to suggest
a way how we can achieve it?
On Tue, Dec 3, 2013 at 12:42 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/02/2013 10:45
On 11/26/2013 08:27 AM, Mark Trompell wrote:
> Answering my own mail again and even top posting, sorry, but makes
> more sense to me in that case).
> I reverted bridge related patches from 3.11.5 and it boils down to
> commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
> Author: Herbert Xu
> Date:
On 11/25/2013 08:03 PM, Sun Paul wrote:
> Hi
>
> we have a problem on using LKSCTP to form a 4 ways multi-homing network.
>
> Configuration
> - Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
> IP-B (eth2)
> - Node-B has 2 IP addresses in different subnets, known as IP-X
On 11/25/2013 08:03 PM, Sun Paul wrote:
Hi
we have a problem on using LKSCTP to form a 4 ways multi-homing network.
Configuration
- Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
IP-B (eth2)
- Node-B has 2 IP addresses in different subnets, known as IP-X (eth1),
On 11/26/2013 08:27 AM, Mark Trompell wrote:
Answering my own mail again and even top posting, sorry, but makes
more sense to me in that case).
I reverted bridge related patches from 3.11.5 and it boils down to
commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
Author: Herbert Xu
nt won't notice the dropping packet in macvtap tx path.
>
> Cc: Michael S. Tsirkin
> Cc: Vlad Yasevich
Acked-by: Vlad Yasevich
-vlad
> Cc: Eric Dumazet
> Signed-off-by: Jason Wang
> ---
> drivers/net/macvtap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
quot;sctp: remove
> 'resent' bit from the chunk") which inappropriately removed the
> 'resent' bit completely, instead of doing this, we should set
> the resent bit only for the retransmitted DATA chunks.
>
> Signed-off-by: Xufeng Zhang
Acked-by: Vlad Yasevich
T
'resent' bit from the chunk) which inappropriately removed the
'resent' bit completely, instead of doing this, we should set
the resent bit only for the retransmitted DATA chunks.
Signed-off-by: Xufeng Zhang xufeng.zh...@windriver.com
Acked-by: Vlad Yasevich vyasev...@gmail.com
Thanks
-vlad
packet in macvtap tx path.
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Vlad Yasevich vyase...@redhat.com
Acked-by: Vlad Yasevich vyase...@redhat.com
-vlad
Cc: Eric Dumazet eduma...@google.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
drivers/net/macvtap.c | 2 +-
1 file changed, 1
On 11/23/2013 06:14 AM, Chang wrote:
> Hi,
> Could you please why a **reneged** newly acked TSN doesn't qualify the
> highest_new_tsn? What's the wrongs of doing that?
>
> I've been thinking a few scenarios, but I couldn't figure out what's
> wrong with that.
>
The spec is a bit conflicting on
On 11/23/2013 06:14 AM, Chang wrote:
Hi,
Could you please why a **reneged** newly acked TSN doesn't qualify the
highest_new_tsn? What's the wrongs of doing that?
I've been thinking a few scenarios, but I couldn't figure out what's
wrong with that.
The spec is a bit conflicting on this
On 11/22/2013 02:24 PM, Chang wrote:
>
> On 11/22/2013 03:27 PM, Vlad Yasevich wrote:
>> On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
>>> tsn_gap_acked is an important state flag in chunk, which indicates if
>>> the
>>> chunk has been acked in ga
On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
> tsn_gap_acked is an important state flag in chunk, which indicates if the
> chunk has been acked in gap reports before.
Actually, this bit indicates simply that the chunk has been acked. It
doesn't state whether it's been acked in a gap report or
On 11/22/2013 03:30 AM, Xufeng Zhang wrote:
> From: Signed-off-by: Xufeng Zhang
>
> Currently retransmitted DATA chunks could also be used for
> RTT measurements since there are no flag to identify whether
> the transmitted DATA chunk is a new one or a retransmitted one.
> This problem is
On 11/22/2013 03:30 AM, Xufeng Zhang wrote:
From: Signed-off-by: Xufeng Zhang xufeng.zh...@windriver.com
Currently retransmitted DATA chunks could also be used for
RTT measurements since there are no flag to identify whether
the transmitted DATA chunk is a new one or a retransmitted one.
On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
tsn_gap_acked is an important state flag in chunk, which indicates if the
chunk has been acked in gap reports before.
Actually, this bit indicates simply that the chunk has been acked. It
doesn't state whether it's been acked in a gap report or
On 11/22/2013 02:24 PM, Chang wrote:
On 11/22/2013 03:27 PM, Vlad Yasevich wrote:
On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
tsn_gap_acked is an important state flag in chunk, which indicates if
the
chunk has been acked in gap reports before.
Actually, this bit indicates simply
On 11/15/2013 05:04 PM, Chang wrote:
>
> On 11/15/2013 03:34 AM, Vlad Yasevich wrote:
>> I don't think this is right. The spec states:
>> 8. ACKs for retransmissions do not transition a PF destination back
>>to Active state, since a sender cannot disambiguate w
andard is 5"?
Path.Max.Retrans is set to 5 (at least on my system...)
-vlad
Thanks!
On 11/15/2013 03:56 PM, Neil Horman wrote:
On Fri, Nov 15, 2013 at 09:00:58AM -0500, Vlad Yasevich wrote:
On 11/15/2013 07:30 AM, Neil Horman wrote:
On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
On 11/
On 11/15/2013 07:30 AM, Neil Horman wrote:
On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
Expected Behavior:
When hearing an ack from a tranport/path, set its state to normal/on if it's
in abnormal(__partial_failure__ or inactive
On 11/15/2013 07:30 AM, Neil Horman wrote:
On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
Expected Behavior:
When hearing an ack from a tranport/path, set its state to normal/on if it's
in abnormal(__partial_failure__ or inactive
is set to 5 (at least on my system...)
-vlad
Thanks!
On 11/15/2013 03:56 PM, Neil Horman wrote:
On Fri, Nov 15, 2013 at 09:00:58AM -0500, Vlad Yasevich wrote:
On 11/15/2013 07:30 AM, Neil Horman wrote:
On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
On 11/14/2013 03:40 PM
On 11/15/2013 05:04 PM, Chang wrote:
On 11/15/2013 03:34 AM, Vlad Yasevich wrote:
I don't think this is right. The spec states:
8. ACKs for retransmissions do not transition a PF destination back
to Active state, since a sender cannot disambiguate whether the
ack
On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
Expected Behavior:
When hearing an ack from a tranport/path, set its state to normal/on if it's
in abnormal(__partial_failure__ or inactive) state.
state machine of tranport->state
Whenever a T3_RTX timer expires, then transport->error_count++.
On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
Expected Behavior:
When hearing an ack from a tranport/path, set its state to normal/on if it's
in abnormal(__partial_failure__ or inactive) state.
state machine of tranport-state
Whenever a T3_RTX timer expires, then transport-error_count++.
When
On 11/13/2013 03:48 PM, Chang wrote:
On 11/13/2013 08:10 PM, Daniel Borkmann wrote:
On 11/13/2013 08:06 PM, Chang wrote:
On 11/13/2013 09:44 AM, Daniel Borkmann wrote:
On 11/13/2013 03:54 AM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong
On 11/12/2013 09:54 PM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to
active_path
and retran_path respectively
Signed-off-by: changxiangzh...@gmail.com
---
net/sctp
On 11/12/2013 09:54 PM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to
active_path
and retran_path respectively
Signed-off-by: changxiangzh...@gmail.com
---
net/sctp
On 11/13/2013 03:48 PM, Chang wrote:
On 11/13/2013 08:10 PM, Daniel Borkmann wrote:
On 11/13/2013 08:06 PM, Chang wrote:
On 11/13/2013 09:44 AM, Daniel Borkmann wrote:
On 11/13/2013 03:54 AM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to active_path
and retran_path respectively
Signed-off-by: changxiangzh...@gmail.com
---
net/sctp/associola.c |4
1 file changed, 4 insertions(+)
diff --git
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to active_path
and retran_path respectively
Signed-off-by: changxiangzh...@gmail.com
---
net/sctp/associola.c |4
1 file changed, 4 insertions(+)
diff --git
On 10/21/2013 06:45 PM, David Miller wrote:
From: Linus Lüssing
Date: Sun, 20 Oct 2013 00:58:57 +0200
While this commit was a good attempt to fix issues occuring when no
multicast querier is present, this commit still has two more issues:
1) There are cases where mdb entries do not expire
On 10/21/2013 06:45 PM, David Miller wrote:
From: Linus Lüssing linus.luess...@web.de
Date: Sun, 20 Oct 2013 00:58:57 +0200
While this commit was a good attempt to fix issues occuring when no
multicast querier is present, this commit still has two more issues:
1) There are cases where mdb
On Oct 19, 2013, at 7:49 AM, Geyslan Gregório Bem wrote:
> 2013/10/19 Geyslan Gregório Bem :
>> Hi maintainers,
>>
>> I would like to know if these are catches:
>>
>> /net/sctp/endpointola.c (281)
>> static void sctp_endpoint_destroy(struct sctp_endpoint *ep)
>> {
>>struct sock *sk;
>>
On Oct 19, 2013, at 7:49 AM, Geyslan Gregório Bem geys...@gmail.com wrote:
2013/10/19 Geyslan Gregório Bem geys...@gmail.com:
Hi maintainers,
I would like to know if these are catches:
/net/sctp/endpointola.c (281)
static void sctp_endpoint_destroy(struct sctp_endpoint *ep)
{
On 10/18/2013 08:58 AM, Mark Brown wrote:
Today's linux-next merge of the next-next tree got a conflict in
include/net/dst.h between e87b3998d (net: dst: provide accessor function
to dst->xfrm) in the net tree and a4023dd01 (dst.h: Remove extern from
function prototypes) in net-next.
I've fixed
On 10/18/2013 08:58 AM, Mark Brown wrote:
Today's linux-next merge of the next-next tree got a conflict in
include/net/dst.h between e87b3998d (net: dst: provide accessor function
to dst-xfrm) in the net tree and a4023dd01 (dst.h: Remove extern from
function prototypes) in net-next.
I've fixed
On 10/15/2013 02:13 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
Your proposed solution is very nice, but it does 2 things in one
patch.
1) It fixes the bug
2) It refactors the code to improve the flow.
While (2) is very nice, it needs a much more careful review.
Can you
On 10/15/2013 01:39 PM, Chang wrote:
On 10/15/2013 07:25 PM, Vlad Yasevich wrote:
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142
---
1 file changed, 68 insertions(+), 74
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142 ---
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 94df758..f10d848
On 10/15/2013 10:27 AM, Chang wrote:
On 10/15/2013 04:11 PM, Vlad Yasevich wrote:
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
For for each TSN t being newly acked (Not only cumulatively,
but also SELECTIVELY) cacc_saw_newack should be set to 1.
Signed-off-by: Xiangzhong Chang
---
net
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
For for each TSN t being newly acked (Not only cumulatively,
but also SELECTIVELY) cacc_saw_newack should be set to 1.
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 42 +-
1 file changed,
On 10/15/2013 02:13 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang changxiangzh...@gmail.com
Your proposed solution is very nice, but it does 2 things in one
patch.
1) It fixes the bug
2) It refactors the code to improve the flow.
While (2) is very nice, it needs a much more
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
For for each TSN t being newly acked (Not only cumulatively,
but also SELECTIVELY) cacc_saw_newack should be set to 1.
Signed-off-by: Xiangzhong Chang changxiangzh...@gmail.com
---
net/sctp/outqueue.c | 42
On 10/15/2013 10:27 AM, Chang wrote:
On 10/15/2013 04:11 PM, Vlad Yasevich wrote:
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
For for each TSN t being newly acked (Not only cumulatively,
but also SELECTIVELY) cacc_saw_newack should be set to 1.
Signed-off-by: Xiangzhong Chang
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang changxiangzh...@gmail.com
---
net/sctp/outqueue.c | 142 ---
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/net/sctp/outqueue.c
On 10/15/2013 01:39 PM, Chang wrote:
On 10/15/2013 07:25 PM, Vlad Yasevich wrote:
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang changxiangzh...@gmail.com
---
net/sctp/outqueue.c | 142
---
1 file changed, 68
is as unnecessary as
using auto to declare automatic/local variables in a block.
Signed-off-by: Joe Perches
looks simple enough.
Acked-by: Vlad Yasevich
-vlad
---
include/net/sctp/sctp.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sctp.h b
is as unnecessary as
using auto to declare automatic/local variables in a block.
Signed-off-by: Joe Perches j...@perches.com
looks simple enough.
Acked-by: Vlad Yasevich vyasev...@gmail.com
-vlad
---
include/net/sctp/sctp.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions
On 08/13/2013 06:54 PM, David Miller wrote:
From: Vlad Yasevich
Date: Mon, 12 Aug 2013 15:57:29 -0400
On 08/12/2013 12:30 PM, Asbjoern Sloth Toennesen wrote:
Fix the iproute2 command `bridge vlan show`, after switching from
rtgenmsg to ifinfomsg.
Signed-off-by: Asbjoern Sloth Toennesen
On 08/13/2013 06:54 PM, David Miller wrote:
From: Vlad Yasevich vyase...@redhat.com
Date: Mon, 12 Aug 2013 15:57:29 -0400
On 08/12/2013 12:30 PM, Asbjoern Sloth Toennesen wrote:
Fix the iproute2 command `bridge vlan show`, after switching from
rtgenmsg to ifinfomsg.
Signed-off-by: Asbjoern
On 08/12/2013 12:30 PM, Asbjoern Sloth Toennesen wrote:
Fix the iproute2 command `bridge vlan show`, after switching from
rtgenmsg to ifinfomsg.
Signed-off-by: Asbjoern Sloth Toennesen
Thanks.. I've still been using an older iproute version and didn't see
this.
Reviewed-by: Vlad
-by: Vlad Yasevich vyasev...@gmail.com
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 3de7408..a043171 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2384,7 +2384,7 @@ static int
f-by: Yann Droneaud
Acked-by: Vlad Yasevich
-vlad
---
net/sctp/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 66fcdcf..caa5919 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4320,7 +4320,7 @@
Droneaud ydrone...@opteya.com
Acked-by: Vlad Yasevich vyasev...@gmail.com
-vlad
---
net/sctp/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 66fcdcf..caa5919 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
On 03/18/2013 04:32 PM, Neil Horman wrote:
On Mon, Mar 18, 2013 at 11:31:06AM -0400, Vlad Yasevich wrote:
On 03/18/2013 11:25 AM, Eric Dumazet wrote:
On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
I'm not sure why the process would never get back to the schedule, but looking
On 03/18/2013 11:25 AM, Eric Dumazet wrote:
On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
I'm not sure why the process would never get back to the schedule, but looking
at the sctp_remaddr_seq_show function, I think that we should convert this
sequence:
sctp_local_bh_disable();
On 03/18/2013 11:25 AM, Eric Dumazet wrote:
On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
I'm not sure why the process would never get back to the schedule, but looking
at the sctp_remaddr_seq_show function, I think that we should convert this
sequence:
sctp_local_bh_disable();
On 03/18/2013 04:32 PM, Neil Horman wrote:
On Mon, Mar 18, 2013 at 11:31:06AM -0400, Vlad Yasevich wrote:
On 03/18/2013 11:25 AM, Eric Dumazet wrote:
On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
I'm not sure why the process would never get back to the schedule, but looking
(chunk, >transmitted,
transmitted_list) {
if (key == chunk->subh.data_hdr->tsn) {
Acked-by: Vlad Yasevich
-vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
;
list_for_each_entry(chunk, transport-transmitted,
transmitted_list) {
if (key == chunk-subh.data_hdr-tsn) {
Acked-by: Vlad Yasevich vyasev...@gmail.com
-vlad
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 03/12/2013 11:44 AM, Neil Horman wrote:
On Tue, Mar 12, 2013 at 08:11:34AM -0400, Vlad Yasevich wrote:
On 03/11/2013 09:31 AM, Neil Horman wrote:
On Mon, Mar 11, 2013 at 10:14:50AM +0800, Xufeng Zhang wrote:
On 3/8/13, Neil Horman wrote:
On Fri, Mar 08, 2013 at 03:39:37PM +0800, Xufeng
On 03/11/2013 09:31 AM, Neil Horman wrote:
On Mon, Mar 11, 2013 at 10:14:50AM +0800, Xufeng Zhang wrote:
On 3/8/13, Neil Horman wrote:
On Fri, Mar 08, 2013 at 03:39:37PM +0800, Xufeng Zhang wrote:
sctp_assoc_lookup_tsn() function searchs which transport a certain TSN
was sent on, if not
On 03/11/2013 09:31 AM, Neil Horman wrote:
On Mon, Mar 11, 2013 at 10:14:50AM +0800, Xufeng Zhang wrote:
On 3/8/13, Neil Horman nhor...@tuxdriver.com wrote:
On Fri, Mar 08, 2013 at 03:39:37PM +0800, Xufeng Zhang wrote:
sctp_assoc_lookup_tsn() function searchs which transport a certain TSN
was
On 03/12/2013 11:44 AM, Neil Horman wrote:
On Tue, Mar 12, 2013 at 08:11:34AM -0400, Vlad Yasevich wrote:
On 03/11/2013 09:31 AM, Neil Horman wrote:
On Mon, Mar 11, 2013 at 10:14:50AM +0800, Xufeng Zhang wrote:
On 3/8/13, Neil Horman nhor...@tuxdriver.com wrote:
On Fri, Mar 08, 2013 at 03:39
On 02/21/2013 11:45 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close examination of
-by: Vlad Yasevich
-vlad
---
net/sctp/ulpqueue.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff
linux-3.8-SCTP+2/net/sctp/ulpqueue.c linux-3.8-SCTP+3/net/sctp/ulpqueue.c
--- linux-3.8-SCTP+2/net/sctp
of reassembly queue shows
missing packets.
In sctp_ulpq_renege_list(), do not renege packets below the
cumulative TSN ACK point.
Patch applies to linux-3.8 kernel.
Signed-off-by: Lee A. Roberts
Acked-by: Vlad Yasevich
-vlad
---
net/sctp/ulpqueue.c |9 +++--
1 file changed, 7
On 02/21/2013 11:44 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association lobby (ordering)
queue. Close examination of reassembly/ordering
On 02/21/2013 11:44 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts lee.robe...@hp.com
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association lobby (ordering)
queue. Close examination of
examination of reassembly queue shows
missing packets.
In sctp_ulpq_renege_list(), do not renege packets below the
cumulative TSN ACK point.
Patch applies to linux-3.8 kernel.
Signed-off-by: Lee A. Roberts lee.robe...@hp.com
Acked-by: Vlad Yasevich vyasev...@gmail.com
-vlad
---
net/sctp
A. Roberts lee.robe...@hp.com
Acked-by: Vlad Yasevich vyasev...@gmail.com
-vlad
---
net/sctp/ulpqueue.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff
linux-3.8-SCTP+2/net/sctp/ulpqueue.c linux-3.8-SCTP+3
On 02/21/2013 11:45 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts lee.robe...@hp.com
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close
On 02/20/2013 02:24 PM, Roberts, Lee A. wrote:
Vlad,
-Original Message-
From: Vlad Yasevich [mailto:vyasev...@gmail.com]
Sent: Wednesday, February 20, 2013 11:06 AM
To: Roberts, Lee A.
Cc: linux-s...@vger.kernel.org; net...@vger.kernel.org; linux-
ker...@vger.kernel.org
Subject: Re
Hi Lee
On 02/20/2013 10:56 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close
On 02/20/2013 10:55 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close examination of
On 02/20/2013 10:55 AM, Roberts, Lee A. wrote:
From: Lee A. Roberts lee.robe...@hp.com
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close
101 - 200 of 338 matches
Mail list logo
