Re: [tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-09-01 Thread Parthasarathy Bhuvaragan
Hi,

I ran the test against latest netnext without my changes and they still fail. I
tried to reduce the bursts for multicast but it did not help.

On the instance below, it failed on subtest-1 of multicast (test-12). The test
just sends 1 packet of 100bytes. I just managed to recreate this and wanted to
inform you.

On the server:

Server says test # 12
detecting synchronization signal 100
acknowledging synchronization signal 100
detecting end of synchronization signal 100
end of synchronization signal 100
TIPC Server Multicast (RDM) test...STARTED!
AF_TIPC:NAMESEQ=(72,0,99)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,0,99)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,100,199)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,200,299)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,200,299)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,300,399)Socket bind for multicast successful
sending synchronization signal 1
sent synchronization signal 1
got ack for synchronization signal 1
detecting synchronization signal 3
acknowledging synchronization signal 3
detecting end of synchronization signal 3
end of synchronization signal 3
===>Starting SubTest 1
Received on 0 sockets in subtest 0, expected 3
===>Finished SubTest 1: received 0 msgs of sz -1 at 3 sockets (1 per socket)
TEST FAILED Received wrong number of multicast messages
 errno = 110: Connection timed out

On the client:

Test # 12
detecting synchronization signal 99
acknowledging synchronization signal 99
detecting end of synchronization signal 99
end of synchronization signal 99
sending synchronization signal 100
sent synchronization signal 100
got ack for synchronization signal 100
TIPC Multicast (RDM) test...STARTED!
client_test_multicast:
detecting synchronization signal 1
acknowledging synchronization signal 1
detecting end of synchronization signal 1
end of synchronization signal 1
sending synchronization signal 3
sent synchronization signal 3
got ack for synchronization signal 3
===> Starting multicast subtest #1
detecting synchronization signal 4
!! = HANGS here === !!


On 08/30/2016 01:34 PM, Jon Maloy wrote:
> The multicast failure is known. It happens because I lowered the socket
> receive buffer size in commit 10724cc7bb783 ("tipc: redesign connection-level
> flow control") so that the send stream now occasionally get too big, and a
> message is rejected. I don't consider this an error, as a multicast sender
> always has to expect and prepare his code for such events.  I have not seen
> the problem in test #6, but it is easily imaginable that this is the same 
> issue.
>
> ///jon
>
>
>
> On 08/30/2016 06:02 AM, Xue, Ying wrote:
>>
>> Just a reminder: this issues might not be caused by your patches. So firstly
>> we need to identify if your patch set leads to the side effects. If not, they
>> are introduced by previous commits merged into mainline.
>>
>> Regards,
>>
>> Ying
>>
>> *From:*Parthasarathy Bhuvaragan 
>> [mailto:parthasarathy.bhuvara...@ericsson.com]
>> *Sent:* Tuesday, August 30, 2016 4:30 PM
>> *To:* Xue, Ying; tipc-discussion@lists.sourceforge.net;
>> jon.ma...@ericsson.com; ma...@donjonn.com
>> *Subject:* Re: [PATCH net-next v2 00/12] tipc: create socket FSM using
>> sk_state only
>>
>> Hi Ying,
>>
>> I tried to trigger this fault. I get a different error on the multicast test,
>> after about 2 hours.
>>  node1 ~ # ./tipcTS
>>  Received on 1 sockets in subtest 6, expected 2
>>  TEST FAILED Received wrong number of multicast messages
>>   errno = 11: Resource temporarily unavailable
>>
>> My client and server run on 2 qemu-guest's with 4 cpus. I will continue to
>> investigate this. Sorry for the late reply, as I got stuck with other issues
>> recently and couldn't focus on this.
>>
>> regards partha
>>
>> On 08/17/2016 12:40 PM, Xue, Ying wrote:
>>
>> I have found the following issue after the series is applied to the
>> latest kernel:
>>
>> Test # 8
>>
>> TIPC TIPC_IMPORTANCE test...STARTED!
>>
>> TEST FAILED unexpected number of send() errors errno = 113: No route to 
>> host
>>
>> Test # 1
>>
>> Below is the procedure of how to reproduce above error:
>>
>> Prepare for two nodes. One is to run "tipcTS"; and on another node, we
>> use the below commands to repeatedly run tipcTC test case:
>>
>> while [ true ]; do tipcTC 0; done
>>
>> About after 2 or 3 hours, the error above will appear.
>>
>> Regards,
>>
>> Ying
>>
>> -Original Message-
>>
>> From: Parthasarathy Bhuvaragan
>> [mailto:parthasarathy.bhuvara...@ericsson.com]
>>
>> Sent: Monday, August 15, 2016 5:19 PM
>>
>> To:tipc-discussion@lists.sourceforge.net
>> ;jon.ma...@ericsson.com
>> ;ma...@donjonn.com ;
>> Xue, Ying
>>
>> Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state
>> only
>>
>> The following 

Re: [tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-08-30 Thread Jon Maloy
The multicast failure is known. It happens because I lowered the socket 
receive buffer size in commit 10724cc7bb783 ("tipc: redesign 
connection-level flow control") so that the send stream now occasionally 
get too big, and a message is rejected. I don't consider this an error, 
as a multicast sender always has to expect and prepare his code for such 
events.  I have not seen the problem in test #6, but it is easily 
imaginable that this is the same issue.

///jon



On 08/30/2016 06:02 AM, Xue, Ying wrote:
>
> Just a reminder: this issues might not be caused by your patches. So 
> firstly we need to identify if your patch set leads to the side 
> effects. If not, they are introduced by previous commits merged into 
> mainline.
>
> Regards,
>
> Ying
>
> *From:*Parthasarathy Bhuvaragan 
> [mailto:parthasarathy.bhuvara...@ericsson.com]
> *Sent:* Tuesday, August 30, 2016 4:30 PM
> *To:* Xue, Ying; tipc-discussion@lists.sourceforge.net; 
> jon.ma...@ericsson.com; ma...@donjonn.com
> *Subject:* Re: [PATCH net-next v2 00/12] tipc: create socket FSM using 
> sk_state only
>
> Hi Ying,
>
> I tried to trigger this fault. I get a different error on the 
> multicast test, after about 2 hours.
>  node1 ~ # ./tipcTS
>  Received on 1 sockets in subtest 6, expected 2
>  TEST FAILED Received wrong number of multicast messages
>   errno = 11: Resource temporarily unavailable
>
> My client and server run on 2 qemu-guest's with 4 cpus. I will 
> continue to investigate this. Sorry for the late reply, as I got stuck 
> with other issues recently and couldn't focus on this.
>
> regards partha
>
> On 08/17/2016 12:40 PM, Xue, Ying wrote:
>
> I have found the following issue after the series is applied to the 
> latest kernel:
>
> Test # 8
>
> TIPC TIPC_IMPORTANCE test...STARTED!
>
> TEST FAILED unexpected number of send() errors errno = 113: No route to 
> host
>
> Test # 1
>
> Below is the procedure of how to reproduce above error:
>
> Prepare for two nodes. One is to run "tipcTS"; and on another node, we 
> use the below commands to repeatedly run tipcTC test case:
>
> while [ true ]; do tipcTC 0; done
>
> About after 2 or 3 hours, the error above will appear.
>
> Regards,
>
> Ying
>
> -Original Message-
>
> From: Parthasarathy Bhuvaragan 
> [mailto:parthasarathy.bhuvara...@ericsson.com]
>
> Sent: Monday, August 15, 2016 5:19 PM
>
> To:tipc-discussion@lists.sourceforge.net
> ;jon.ma...@ericsson.com 
> ;ma...@donjonn.com ; 
> Xue, Ying
>
> Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state 
> only
>
> The following issues with the current socket layer hinders socket 
> diagnostics implementation, which led to this patch series. The series does 
> not add any functional change.
>
> 1. tipc socket state is derived from multiple variables like
>
> sock->state, tsk->probing_state and tsk->connected. This style forces
>
> us to export multiple attributes to the user space, which has to be
>
> backward compatible.
>
> 2. Abuse of sock->state cannot be exported to user-space without
>
> requiring tipc specific hacks in the user-space.
>
> - For connection less (CL) sockets sock->state is overloaded to
>
>   tipc state SS_READY.
>
> - For connection oriented (CO) listening socket sock->state is
>
>   overloaded to tipc state SS_LISTEN.
>
> This series is split into three:
>
> 1. A bug fix in patch-1
>
> 2. Express all tipc states using a single variable. This is done in 
> patch#2-5.
>
> 3. Migrate the new tipc states to sk->sk_state. This is done in 
> patch#6-12.
>
> The figures below represents the FSM after this series:
>
> Unconnected Sockets:
>
> +--+++
>
> | TIPC_UNCONNECTED |--->| TIPC_DISCONNECTING |
>
> +--+++
>
> Stream Server Listening Socket:
>
> +--++-+
>
> | TIPC_UNCONNECTED |--->| TIPC_LISTEN |
>
> +--++-+
>
>|
>
> ++|
>
> | TIPC_DISCONNECTING |<---+
>
> ++
>
> Stream Server Data Socket:
>
> +-++--+
>
> |TIPC_UNCONNECTED |--> | TIPC_ESTABLISHED |<---+
>
> +-++--+|
>
> ^   ||  |
>
> |   |+--+
>
> |   v
>
> +--+  +-+
>
> |TIPC_DISCONNECTING|<-|TIPC_PROBING |
>
> +--+  +-+
>
> Stream Socket Client:
>
> 

Re: [tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-08-30 Thread Xue, Ying
Just a reminder: this issues might not be caused by your patches. So firstly we 
need to identify if your patch set leads to the side effects. If not, they are 
introduced by previous commits merged into mainline.

Regards,
Ying

From: Parthasarathy Bhuvaragan [mailto:parthasarathy.bhuvara...@ericsson.com]
Sent: Tuesday, August 30, 2016 4:30 PM
To: Xue, Ying; tipc-discussion@lists.sourceforge.net; jon.ma...@ericsson.com; 
ma...@donjonn.com
Subject: Re: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state 
only


Hi Ying,

I tried to trigger this fault. I get a different error on the multicast test, 
after about 2 hours.
 node1 ~ # ./tipcTS
 Received on 1 sockets in subtest 6, expected 2
 TEST FAILED Received wrong number of multicast messages
  errno = 11: Resource temporarily unavailable

My client and server run on 2 qemu-guest's with 4 cpus. I will continue to 
investigate this. Sorry for the late reply, as I got stuck with other issues 
recently and couldn't focus on this.

regards partha

On 08/17/2016 12:40 PM, Xue, Ying wrote:

I have found the following issue after the series is applied to the latest 
kernel:



Test # 8

TIPC TIPC_IMPORTANCE test...STARTED!

TEST FAILED unexpected number of send() errors errno = 113: No route to host

Test # 1



Below is the procedure of how to reproduce above error:

Prepare for two nodes. One is to run "tipcTS"; and on another node, we use the 
below commands to repeatedly run tipcTC test case:



while [ true ]; do tipcTC 0; done



About after 2 or 3 hours, the error above will appear.



Regards,

Ying



-Original Message-

From: Parthasarathy Bhuvaragan [mailto:parthasarathy.bhuvara...@ericsson.com]

Sent: Monday, August 15, 2016 5:19 PM

To: 
tipc-discussion@lists.sourceforge.net;
 jon.ma...@ericsson.com; 
ma...@donjonn.com; Xue, Ying

Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only



The following issues with the current socket layer hinders socket diagnostics 
implementation, which led to this patch series. The series does not add any 
functional change.



1. tipc socket state is derived from multiple variables like

   sock->state, tsk->probing_state and tsk->connected. This style forces

   us to export multiple attributes to the user space, which has to be

   backward compatible.



2. Abuse of sock->state cannot be exported to user-space without

   requiring tipc specific hacks in the user-space.

   - For connection less (CL) sockets sock->state is overloaded to

 tipc state SS_READY.

   - For connection oriented (CO) listening socket sock->state is

 overloaded to tipc state SS_LISTEN.



This series is split into three:

1. A bug fix in patch-1

2. Express all tipc states using a single variable. This is done in patch#2-5.

3. Migrate the new tipc states to sk->sk_state. This is done in patch#6-12.



The figures below represents the FSM after this series:



Unconnected Sockets:

+--+++

| TIPC_UNCONNECTED |--->| TIPC_DISCONNECTING |

+--+++



Stream Server Listening Socket:

+--++-+

| TIPC_UNCONNECTED |--->| TIPC_LISTEN |

+--++-+

  |

++|

| TIPC_DISCONNECTING |<---+

++



Stream Server Data Socket:

+-++--+

|TIPC_UNCONNECTED |--> | TIPC_ESTABLISHED |<---+

+-++--+|

   ^   ||  |

   |   |+--+

   |   v

+--+  +-+

|TIPC_DISCONNECTING|<-|TIPC_PROBING |

+--+  +-+



Stream Socket Client:

+-+   +-+

|TIPC_UNCONNECTED |-->| TIPC_CONNECTING |

+-+   +-+

  |

  |

  v

  +--+

  | TIPC_ESTABLISHED |<---+

  +--+|

   ^   || |

   |   |+-+

   |   v

+--+  +-+

|TIPC_DISCONNECTING|<-|TIPC_PROBING |

+--+  +-+



NOTE:

This is just a base refractoring required for socket diagnostics.

Implementation of TIPC socket diagnostics will be sent as a separate series.



v2: - Address comments from Ying Xue 
 in

  patch #4, #5, #12.

- Added a note that the 

Re: [tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-08-30 Thread Parthasarathy Bhuvaragan
Hi Ying,

I tried to trigger this fault. I get a different error on the multicast test,
after about 2 hours.
 node1 ~ # ./tipcTS
 Received on 1 sockets in subtest 6, expected 2
 TEST FAILED Received wrong number of multicast messages
  errno = 11: Resource temporarily unavailable

My client and server run on 2 qemu-guest's with 4 cpus. I will continue to
investigate this. Sorry for the late reply, as I got stuck with other issues
recently and couldn't focus on this.

regards partha


On 08/17/2016 12:40 PM, Xue, Ying wrote:
> I have found the following issue after the series is applied to the latest 
> kernel:
>
> Test # 8
> TIPC TIPC_IMPORTANCE test...STARTED!
> TEST FAILED unexpected number of send() errors errno = 113: No route to host
> Test # 1
>
> Below is the procedure of how to reproduce above error:
> Prepare for two nodes. One is to run "tipcTS"; and on another node, we use 
> the below commands to repeatedly run tipcTC test case:
>
> while [ true ]; do tipcTC 0; done
>
> About after 2 or 3 hours, the error above will appear.
>
> Regards,
> Ying
>
> -Original Message-
> From: Parthasarathy Bhuvaragan [mailto:parthasarathy.bhuvara...@ericsson.com] 
> Sent: Monday, August 15, 2016 5:19 PM
> To: tipc-discussion@lists.sourceforge.net; jon.ma...@ericsson.com; 
> ma...@donjonn.com; Xue, Ying
> Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only
>
> The following issues with the current socket layer hinders socket diagnostics 
> implementation, which led to this patch series. The series does not add any 
> functional change.
>
> 1. tipc socket state is derived from multiple variables like
>sock->state, tsk->probing_state and tsk->connected. This style forces
>us to export multiple attributes to the user space, which has to be
>backward compatible.
>
> 2. Abuse of sock->state cannot be exported to user-space without
>requiring tipc specific hacks in the user-space.
>- For connection less (CL) sockets sock->state is overloaded to
>  tipc state SS_READY.
>- For connection oriented (CO) listening socket sock->state is
>  overloaded to tipc state SS_LISTEN.
>
> This series is split into three:
> 1. A bug fix in patch-1
> 2. Express all tipc states using a single variable. This is done in patch#2-5.
> 3. Migrate the new tipc states to sk->sk_state. This is done in patch#6-12.
>
> The figures below represents the FSM after this series:
>
> Unconnected Sockets:
> +--+++
> | TIPC_UNCONNECTED |--->| TIPC_DISCONNECTING |
> +--+++
>
> Stream Server Listening Socket:
> +--++-+
> | TIPC_UNCONNECTED |--->| TIPC_LISTEN |
> +--++-+
>   |
> ++|
> | TIPC_DISCONNECTING |<---+
> ++
>
> Stream Server Data Socket:
> +-++--+
> |TIPC_UNCONNECTED |--> | TIPC_ESTABLISHED |<---+
> +-++--+|
>^   ||  |
>|   |+--+
>|   v
> +--+  +-+
> |TIPC_DISCONNECTING|<-|TIPC_PROBING |
> +--+  +-+
>
> Stream Socket Client:
> +-+   +-+
> |TIPC_UNCONNECTED |-->| TIPC_CONNECTING |
> +-+   +-+
>   |
>   |
>   v
>   +--+
>   | TIPC_ESTABLISHED |<---+
>   +--+|
>^   || |
>|   |+-+
>|   v
> +--+  +-+
> |TIPC_DISCONNECTING|<-|TIPC_PROBING |
> +--+  +-+
>
> NOTE:
> This is just a base refractoring required for socket diagnostics.
> Implementation of TIPC socket diagnostics will be sent as a separate series.
>
> v2: - Address comments from Ying Xue  in
>   patch #4, #5, #12.
> - Added a note that the socket diagnostics will be sent as
>   another series.
> v1: - I base the following patch series as the first version:
>   [RFC PATCH v1 00/12] tipc: create socket FSM using sk_state only
>
> Parthasarathy Bhuvaragan (12):
>   tipc: set kern=0 in sk_alloc() during tipc_accept()
>   tipc: rename tsk->remote to tsk->peer for consistent naming
>   tipc: remove tsk->connected for connection less sockets
>   tipc: remove tsk->connected from tipc_sock
>   tipc: remove probing_intv from tipc_sock
>   tipc: remove socket state SS_READY
>   tipc: create TIPC_LISTEN as a new 

Re: [tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-08-17 Thread Xue, Ying
In the final code, it's found there is the following code:

static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
{
struct sock *sk = >sk;
struct net *net = sock_net(sk);
struct tipc_msg *hdr = buf_msg(skb);

if (unlikely(msg_mcast(hdr)))  
return false; 

switch (sk->sk_state) {
case TIPC_CONNECTING: 
/* Accept only ACK or NACK message */
if (unlikely(!msg_connected(hdr)))
return false;  

if (unlikely(msg_errcode(hdr))) { 
tipc_set_state(sk, TIPC_DISCONNECTING);
sk->sk_err = ECONNREFUSED; 
return true;   
}

if (unlikely(!msg_isdata(hdr))) { 
tipc_set_state(sk, TIPC_DISCONNECTING);
sk->sk_err = EINVAL;   
return true;   
}

tipc_sk_finish_conn(tsk, msg_origport(hdr), msg_orignode(hdr));
msg_set_importance(>phdr, msg_importance(hdr));

/* If 'ACK+' message, add to socket receive queue */
if (msg_data_sz(hdr))  
return true;   

/* If empty 'ACK-' message, wake up sleeping connect() */
if (waitqueue_active(sk_sleep(sk)))
wake_up_interruptible(sk_sleep(sk));

/* 'ACK-' message is neither accepted nor rejected: */
msg_set_dest_droppable(hdr, 1);
return false; 

}

switch (sk->sk_state) {   ===> But the 
switch statement should be redundant.
   case TIPC_UNCONNECTED: 

Regards,
Ying

-Original Message-
From: Parthasarathy Bhuvaragan [mailto:parthasarathy.bhuvara...@ericsson.com] 
Sent: Monday, August 15, 2016 5:19 PM
To: tipc-discussion@lists.sourceforge.net; jon.ma...@ericsson.com; 
ma...@donjonn.com; Xue, Ying
Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

The following issues with the current socket layer hinders socket diagnostics 
implementation, which led to this patch series. The series does not add any 
functional change.

1. tipc socket state is derived from multiple variables like
   sock->state, tsk->probing_state and tsk->connected. This style forces
   us to export multiple attributes to the user space, which has to be
   backward compatible.

2. Abuse of sock->state cannot be exported to user-space without
   requiring tipc specific hacks in the user-space.
   - For connection less (CL) sockets sock->state is overloaded to
 tipc state SS_READY.
   - For connection oriented (CO) listening socket sock->state is
 overloaded to tipc state SS_LISTEN.

This series is split into three:
1. A bug fix in patch-1
2. Express all tipc states using a single variable. This is done in patch#2-5.
3. Migrate the new tipc states to sk->sk_state. This is done in patch#6-12.

The figures below represents the FSM after this series:

Unconnected Sockets:
+--+++
| TIPC_UNCONNECTED |--->| TIPC_DISCONNECTING |
+--+++

Stream Server Listening Socket:
+--++-+
| TIPC_UNCONNECTED |--->| TIPC_LISTEN |
+--++-+
  |
++|
| TIPC_DISCONNECTING |<---+
++

Stream Server Data Socket:
+-++--+
|TIPC_UNCONNECTED |--> | TIPC_ESTABLISHED |<---+
+-++--+|
   ^   ||  |
   |   |+--+
   |   v
+--+  +-+
|TIPC_DISCONNECTING|<-|TIPC_PROBING |
+--+  +-+

Stream Socket Client:
+-+   +-+
|TIPC_UNCONNECTED |-->| TIPC_CONNECTING |
+-+   +-+
  |
  |
  v
  +--+
  | TIPC_ESTABLISHED |<---+
  +--+|
   ^   || |
   |   |+-+
   |   v
+--+  +-+
|TIPC_DISCONNECTING|<-|TIPC_PROBING |
+--+  +-+

NOTE:
This is just a base refractoring required for socket diagnostics.
Implementation of TIPC socket diagnostics will be sent as a separate series.

v2: - Address comments from Ying Xue 

[tipc-discussion] [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state only

2016-08-15 Thread Parthasarathy Bhuvaragan
The following issues with the current socket layer hinders socket diagnostics
implementation, which led to this patch series. The series does not add any
functional change.

1. tipc socket state is derived from multiple variables like
   sock->state, tsk->probing_state and tsk->connected. This style forces
   us to export multiple attributes to the user space, which has to be
   backward compatible.

2. Abuse of sock->state cannot be exported to user-space without
   requiring tipc specific hacks in the user-space.
   - For connection less (CL) sockets sock->state is overloaded to
 tipc state SS_READY.
   - For connection oriented (CO) listening socket sock->state is
 overloaded to tipc state SS_LISTEN.

This series is split into three:
1. A bug fix in patch-1
2. Express all tipc states using a single variable. This is done in patch#2-5.
3. Migrate the new tipc states to sk->sk_state. This is done in patch#6-12.

The figures below represents the FSM after this series:

Unconnected Sockets:
+--+++
| TIPC_UNCONNECTED |--->| TIPC_DISCONNECTING |
+--+++

Stream Server Listening Socket:
+--++-+
| TIPC_UNCONNECTED |--->| TIPC_LISTEN |
+--++-+
  |
++|
| TIPC_DISCONNECTING |<---+
++

Stream Server Data Socket:
+-++--+
|TIPC_UNCONNECTED |--> | TIPC_ESTABLISHED |<---+
+-++--+|
   ^   ||  |
   |   |+--+
   |   v
+--+  +-+
|TIPC_DISCONNECTING|<-|TIPC_PROBING |
+--+  +-+

Stream Socket Client:
+-+   +-+
|TIPC_UNCONNECTED |-->| TIPC_CONNECTING |
+-+   +-+
  |
  |
  v
  +--+
  | TIPC_ESTABLISHED |<---+
  +--+|
   ^   || |
   |   |+-+
   |   v
+--+  +-+
|TIPC_DISCONNECTING|<-|TIPC_PROBING |
+--+  +-+

NOTE:
This is just a base refractoring required for socket diagnostics.
Implementation of TIPC socket diagnostics will be sent as a
separate series.

v2: - Address comments from Ying Xue  in
  patch #4, #5, #12.
- Added a note that the socket diagnostics will be sent as
  another series.
v1: - I base the following patch series as the first version:
  [RFC PATCH v1 00/12] tipc: create socket FSM using sk_state only

Parthasarathy Bhuvaragan (12):
  tipc: set kern=0 in sk_alloc() during tipc_accept()
  tipc: rename tsk->remote to tsk->peer for consistent naming
  tipc: remove tsk->connected for connection less sockets
  tipc: remove tsk->connected from tipc_sock
  tipc: remove probing_intv from tipc_sock
  tipc: remove socket state SS_READY
  tipc: create TIPC_LISTEN as a new sk_state
  tipc: create TIPC_PROBING/TIPC_ESTABLISHED as new sk_states
  tipc: create TIPC_UNCONNECTED as a new sk_state
  tipc: create TIPC_DISCONNECTING as a new sk_state
  tipc: create TIPC_CONNECTING as a new sk_state
  tipc: remove SS_CONNECTED sock state

 include/uapi/linux/tipc.h |  12 ++
 net/tipc/socket.c | 340 ++
 2 files changed, 205 insertions(+), 147 deletions(-)

-- 
2.1.4


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion