BTW, I think you should add a reference to the patch where the subscription
refcount was introduced in the log message, so that Andrew will know how far
back he should apply this patch on "stable".
///jon
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Mo
No objections. Just go ahead.
///jon
From: Parthasarathy Bhuvaragan
Sent: Monday, March 20, 2017 12:00 PM
To: Jon Maloy ; John Thompson
Cc: Ying Xue ; tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] [PATCH v2 net-next 6/6] tipc: delete expired
subscription
Hi,
In that c
Hi,
In that case I plan to send the only the first fix to net:
tipc: advance the time of calling tipc_nametbl_unsubscribe
Then wait till net is merged to netnext and submit the following to netnext:
tipc: advance the time of deleting subscription from
subscriber->subscrp_list
tipc: adjus
Series acked by me. Please send to ‘net’ since this problem really occurs
frequently even in the released version.
///jon
From: John Thompson [mailto:thompa@gmail.com]
Sent: Sunday, March 19, 2017 09:19 PM
To: Parthasarathy Bhuvaragan
Cc: Ying Xue ; tipc-discussion@lists.sourceforge.net;
Hi Partha,
If you update according my previous comments,
Reviewed-by: Jon Maloy -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Monday, March 20, 2017 05:10 AM
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy
> ; Ying Xue
> Subject: [PATCH net v1 0/7] tipc socket layer b
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Monday, March 20, 2017 05:10 AM
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy
> ; Ying Xue
> Subject: [PATCH net v1 4/7] tipc: Fix missing connection request handling
>
> In filter_connect, we use waitqueue_active()
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Monday, March 20, 2017 05:10 AM
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy
> ; Ying Xue
> Subject: [PATCH net v1 5/7] tipc: improve error validations for sockets in
> CONNECTING state
>
> Until now, the checks for
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Monday, March 20, 2017 05:10 AM
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy
> ; Ying Xue
> Subject: [PATCH net v1 3/7] tipc: fix flow control accounting for implicit
> connect
>
> In the case of implicit connect me
In filter_connect, we use waitqueue_active() to check for any
connections to wakeup. But waitqueue_active() is missing memory
barriers while accessing the critical sections, leading to
inconsistent results.
In this commit, we replace this with an SMP safe wq_has_sleeper().
Signed-off-by: Parthasa
When we fail to identify a bearer in tipc_node_get_linkname(), we
call node unlock without locking the node read lock. This leads
to node read lock imbalance.
In this commit, we skip the node read unlock for unidentified bearer.
Signed-off-by: Parthasarathy Bhuvaragan
---
net/tipc/node.c | 2 +-
Until now in tipc_send_stream(), we return -1 when the socket
encounters link congestion even if the socket had successfully
sent partial data. This is incorrect as the application resends
the same the partial data leading to data corruption at
receiver's end.
In this commit, we return the partial
This series primarily contains fixes for bugs exposed by
Commit 10724cc7bb78 ("tipc: redesign connection-level flow control").
Patch#1-3: Fixes which are required for the new socket flow control
to work correctly. They fix holes in flow control
accounting.
Patch#4-6: Fixes t
When a socket is shutting down, we notify the peer node about the
connection termination by reusing an incoming message if possible.
If the last received message was a connection acknowledgment
message, we reverse this message and set the error code to
TIPC_ERR_NO_PORT and send it to peer.
In tipc
Until now in tipc_recv_stream(), we update the received
unacknowledged bytes based on a stack variable and not based on the
actual message size.
If the user buffer passed at tipc_recv_stream() is smaller than the
received skb, the size variable in stack differs from the actual
message size in the s
In the case of implicit connect message with data > 1K, the flow
control accounting is incorrect. At this state, the socket does not
know the peer nodes capability and falls back to legacy flow control
by return 1, however the receiver of this message will perform the
new block accounting. This lea
Until now, the checks for sockets in CONNECTING state was based on
the assumption that the incoming message was always from the
peer's accepted data socket.
However an application using a non-blocking socket sends an implicit
connect, this socket which is in CONNECTING state can receive error
mess
16 matches
Mail list logo